**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

_______________________________________
## Short functional explanation of the error

On barcode, when an item isn't picked, when clicking on quality checks,
 the quality check for the unpicked item will still show.

## Reproduction Steps
1. Go to Quality and create a Quality point by clicking on Quality Control. Click on new, set a title and put 2 products in the field Product. In operation, select Receipt.
2. Go to Inventory and click Receipts.
3. Click New. Fill the Receive From field, and add 2 products. Set the demand field to 2 for example.
4. Click on Mark as Todo.
6. Go to Barcode. Click on Operations, the Receipts, and click on the latest Receipt you created.
7. For one product, click on the +2 button. For the other one, leave it at 0. Then, click on Quality Check.

### Expected behavior
Only the quality check for the item that has been picked should show.

### Unexpected behavior
Both quality checks show.

## Origin of the issue
The behavior of the code is different when we perform the operations in backend compared to when we perform them in barcode. Indeed, for the regular flow in Inventory, in ```check_quality()```, we also retrieve the checks linked to a move line that hasn't been picked:
https://github.com/odoo/enterprise/blob/c09a5cbc2450ec32b0ad3985fa2d4e5e2fcd3d71/quality_control/models/stock_picking.py#L44-L58

Which isn't the intended flow for barcode. Thus, we have to change this behavior and take into account the environment. __
opw-5010764

Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.

Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.

Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.

opw-5029870

Steps to reproduce:
-------------------
1. Enable self orderdering, and set an online payment method
2. Open 3 tabs: the main PoS one, the self order one, and the preparation display one (we have to setup the prep display too)
3. In the self order tab, make an order and pay for it

Observe that in the main tab, a receipt modal (window.print) appears, and the order is not sent to the payment display (on the third tab) until we either dismiss or accept the printing popup on the main tab.

Reason:
-------
If there is no printing device connected, we fallback to printing the receipt with `window.print`; this operation blocks the execution of the code that follows it, in our case sending the order to the preparation display, until we either dismiss or confirm the printing popup.

Now if the user is not paying attention to the main tab (only looking at the preparation display for instance), the order will not appear in the prep display.

Fix:
----
In the case of fallbacking to web printing, we execute the print in a `setTimeout`, so to not block the code that comes after it.

opw-5039685

**Issue**
When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback.

**Steps to Reproduce**
1. Create an individual contact and link it to a company.
2. Create a Purchase Order with the individual as a vendor.
3. Create a Vendor Bill with the same individual as the vendor.
4. Try to perform Bill Matching.
5. A `ValueError: Expected singleton: res.partner(...)` is raised.

Video for reference:
https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view

**Root Cause**
Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error.

**Fix**
Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company.

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

Forward-Port-Of: odoo/odoo#226130

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#89290

Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.

Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``

Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.

This operation is allowed for the following groups:
	- Administration/Settings

Contact your administrator to request access if necessary.

ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
            <field name="name">Standard 32 hours/week (4 work days, friday free)</field>
            <field name="company_id" eval="False"/>
            <field name="hours_per_day">8</field>
            <field name="attendance_ids" eval="[(5, 0, 0),                     (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}),                     (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}),                     (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}),                     (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}),                     (0, 0, {'name': 'Tu...

ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n            <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n            <field name="company_id" eval="False"/>\n            <field name="hours_per_day">8</field>\n            <field name="attendance_ids" eval="[(5, 0, 0),                     (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}),                     (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}),                     (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}),                     (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```

This error occurs because the new user has not been granted administrative rights.

This commit resolves the issue by granting the user superuser rights.

sentry-6110523247

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

Forward-Port-Of: odoo/odoo#195714

Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.

Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`

Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
            <field name="user_id" ref="base.user_admin"/>
            <field name="name">Appraisal of Emma Granger</field>
            <field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'),                 ref('hr.work_contact_eg')])]"/>
            <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
            <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
            <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
            <field name="res_model">hr.appraisal</field>
            <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
        </record>

ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n            <field name="user_id" ref="base.user_admin"/>\n            <field name="name">Appraisal of Emma Granger</field>\n            <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'),                 ref(\'hr.work_contact_eg\')])]"/>\n            <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n            <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n            <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n            <field name="res_model">hr.appraisal</field>\n            <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n        </record>') while evaluating
'action = model._load_demo_data()'
```

This error occurs because the new user has not been granted administrative rights.

This commit resolves the issue by granting the user superuser rights.

sentry-6110523247

Forward-Port-Of: odoo/enterprise#93461

Manual forward port of https://github.com/odoo/enterprise/pull/90878

**Problem:**
When scanning a package with a different UoM than the barcode line, the
conversion is not made.

**Steps to reproduce:**
- Enable the "Packages" setting;
- Create a new storable product and set kg as its UoM;
- In the inventory tab, add "g" in the packagings
- Click on the on hand smart button and select update quantity
- Add a new line;
- In the package column create a new package;
- Set a quantity of 10 kg;
- Create a delivery and select your product;
- Set a demand on 10000 and select g as the UoM;
- Mark as todo;
- Open the delivery in the Barcode app;
- Scan the package.

**Current behavior:**
The quantity on the line is now 10 / 10000 g

**Expected behavior:**
It should be 10000 / 10000 g

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505
remaining_qty is expressed in the uom of the quant so it will be 10 but
qty_needed is expressed in the uom of the line is it will be 10000.
qty_used beeing the minimum of those two it will be 10.

**Fix:**
To define how much quantity to take from the package, we convert the
line's quantity by using the package's UoM.
Then, when we add this quantity to the line's quantity, we re-convert it
by using the line's UoM.

opw-4860064

### Issue: 
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

### Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry" 

### Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`.
The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute`
Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

### Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

opw-5056938

This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558).

### Issue: 
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

### Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry" 

### Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`.
The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute`
Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

### Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

opw-5056938

**Step to reproduce:**
- install account module with localization "UAE"
- go to Settings > Tax Included
- create a invoice (make sure a tax is applied)
- print any invoice (Proforma or Tax)

**Observation:**
- the amount is being displayed twice in the Amount column.

**Cause:**
- A change was introduced in 18.0 to add additional column right after Amount
 column, [1] in l10n_ae module
- Another commit [2] in saas-18.3 introduces same column in main account module
- hence we have two columns printing same information

**Fix:**
- Removed and fixed a faulty xpath from view, as after commit [2]
    base layout provides same logic

[1] https://github.com/odoo/odoo/commit/fe68fa30b18f90411043fc6e2314fd376ddaed0c
[2] https://github.com/odoo/odoo/commit/1bf232c22f430d282aaadd858c5e61fed12f4da6

**Before:**
<img width="774" height="146" alt="image" src="https://github.com/user-attachments/assets/a9eb6af2-81b3-4989-bf6e-6676eafe10f8" />

**After:**
<img width="813" height="143" alt="image" src="https://github.com/user-attachments/assets/fb019516-de7d-4dd3-b7dd-3fd14322b031" />

opw-4976410

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

### Steps to reproduce:

- In the settings website > Shop:
    - Disable `Out-of-Stock: Continue Selling`.
    - Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
    - COMP, put 1 unit in stock.
    - KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product

### Cause of the issue:

The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.

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

Forward-Port-Of: odoo/odoo#228537
Forward-Port-Of: odoo/odoo#222945

Steps to reproduce:
- Go to a project
- Open the task list view
- Select a task
- In the `Stage` field, attempt to create a new stage

Issue:
- Project users were able to create new task stages from the task list view, despite not having the required permissions.

Cause:
- The `_default_user_id` method assigns the current user as the owner `user_id` of a new stage only when `default_project_id` is not present in the context. As a result, the method returned the current user’s ID, unintentionally making them the owner of the stage. This allowed project users to bypass the intended access rules and create new stages.

Solution:
- Use the `no_create` option for users outside the project manager group to prevent them from creating new stages.
- Updated the `stage_id` field in the task list view to explicitly include `default_project_id` in the context, ensuring proper access control of that stage.

task-4628666

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

Forward-Port-Of: odoo/odoo#228627
Forward-Port-Of: odoo/odoo#206407