Since [1], the registry is loaded without a request context, so a module installation now goes through the fallback of `get_current_website` that reads the url stored on the current thread. That value is a full url, not the `domain:port` the method expects, so IDNA-encoding it splits it on the dots of the path rather than on those of a host name and raises `UnicodeError` as soon as one of the resulting parts reaches 64 characters.

The thread url is now reduced to its `domain:port` part.

Steps to reproduce:
- Start the server locally on a database with demo data, served on `http://localhost:8069`, with only `Website` installed
- Create a new website
- In the configurator, choose `I want an online store`
- Go through each step
- After the last step, a traceback appears while loading the accounting demo data: the configurator should apply without error

[1]: https://github.com/odoo/odoo/commit/1ae80f9fb18c9c9e67fe0367b94f0d882c711570


Also reported here: https://github.com/odoo/odoo/issues/286432

Forward-Port-Of: odoo/odoo#288931

eproduction steps:
 - MRP subcontracting + purchase
 - Subcontracted product with BOM
 - Create PO with a qty > 1 for this product
 - Go into barcode
 - Scan > 0 and < all of the expected quantity
 - Back out of barcode
 - Click validate -> Error **OR** Go back into barcode, attempt to validate -> Error

Added the StockMove and StockPicking classes to stock_barcode_mrp_subcontracting
to extend functions `_subcontracted_produce`, `_clean_merged`, and `split_uncompleted_moves`
to use a new context flag, `keep_subcontract_production`. When this flag
is set, the move Barcode creates from the split keeps the MO of the move
it was split from rather than splitting the MO in two, gives that link up
before it is merged away so its cancellation does not cancel the MO, and
the MO quantity is resynced with the merged move afterwards.

Error thrown here:
https://github.com/odoo/odoo/blob/f84eeb3ed1421e0cc07c906ff6444734dc01d35f/addons/mrp_subcontracting/models/stock_move.py#L248

opw-6428928

# How to reproduce
- Start a new db with the design-themes addons
- Install the eCommerce module
- Skip the first website configurator
- Go to Website > Configuration > Settings > New website
- Go through all the steps as usual

# The issue
At the last step, you will get, depending on the version either :
- A traceback, pointing out the fact that a template is missing
- A popup signaling that another module operation is being processed,
even though there are none

The configurator won't go through in both cases

# Cause
When calling `configurator_apply`, we will try to get the content of
every snippet specific to theme installed with the website :
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/website.py#L910

But, when trying to find the
'website_sale.configurator_homepage_s_dynamic_snippet_category_list'
view, we find nothing and an error is thrown.

This view should be created by the `_generate_primary_snippet_templates`
function, which is called when loading any theme module or `website`
or `website_sale`:
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/ir_module_module.py#L594

The issue is that, to know which snippets to install, that function
relies on `get_current_website()`:
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/ir_module_module.py#L694

Which relies on multiple things to find the current website, notably
the current request's session :
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/website.py#L1374-L1381

Since [this commit], the request is not kept when creating a new
registry, which is done when loading a module.

`get_current_website()` fallbacks on the first website's theme, which
is the default theme (since we skipped the first configurator). That
theme does not have the `website_sale` snippet in its manifest, contrary
to others.

# Proposed solution
Since a new registry is created, we cannot use the context, nor the
current request. We also cannot add a parameter to the
`_generate_primary_snippet_templates` function since we are in stable
(It would not help much anyway because this function is called when
loading a module, so giving the current website is not possible).

This means that we have to stop relying on `get_current_website()` to
differentiate between the two use case :
- Installing a theme module
- Installing a module with specific snippets

We can determine if the module being installed is a theme by looking at
its category. If it is not, we assume its the other use case as there
should not be any other.

In that case, instead of installing the snippets of the theme of the
current website, we check the theme of all websites.

Later in the code, we take only distincts snippets and check that a
corresponding view do not already exist, so there should be no risk of
duplicate :
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L692
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L712
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L608

Furthermore, I believe it makes more sense to check every website
anyway. If the `website_sale` module is installed, and there already
exists multiple website with different themes, these themes might
require different `website_sale` specific snippets.

opw-6517556

[this commit]: https://github.com/odoo/odoo/commit/be8c85b4ccb10d6f16ddea3ab493e4c9aac749e1

Problem:
Closing the chat window of a chat request sent to a website visitor crashes
with `TypeError: Cannot read properties of undefined (reading '_proxy')`.

Cause:
When a record is deleted, `MAKE_UPDATE` clears it from the relations holding
it. Holders still alive come from `recordByLocalId` as proxies, holders already
deleted in the same update come from `deletingRecordsByLocalId` as raw records.
On a raw record, `usingRecord[one] = undefined` overwrites the `RecordList`
instead of emptying it, and the next read of that field crashes.
Regression from [7432827d09e6](https://github.com/odoo/odoo/commit/7432827d09e667bb1e2670c7bb719fe24edec59d).

Solution:
Backport of [7b457e243bdf](https://github.com/odoo/odoo/commit/7b457e243bdfcdd4c4b61b4771643c1985bde9cf)
from 19.0: always work on the raw record and remove the deleted record from
its `RecordList`, for `one` and `many` fields alike.

Steps to reproduce:

    Set a Livechat channel on the website and add yourself as an operator.
    Website > Reporting > Visitors > click `Chat` on a visitor.
    Close the chat window. => Error dialog with the `TypeError` above.

opw-6564629

Forward-Port-Of: odoo/odoo#288199

### Steps to Reproduce:
1. Go to Sales > Products and select a product
2. Upload an image for the product
3. Go to Settings > Technical > Attachments
4. Click on one of the image attachments
5. Observe the Client Error: "Uncaught Promise > Invalid props for
component 'Many2One': 'domain' is not a function"

### Issue:
In `attachment_patch.js`, the domain for the `Many2OneReferenceField` is overridden when an attachment is linked to another attachment. The patch calculates the domain and incorrectly assigns a static Array (using `.toList()`) to `props.domain`. In Odoo 19, the `Many2One` component enforces strict prop validation (caught when Owl's debug mode is enabled during testing), causing a crash because it expects the domain prop to be a function.

### Solution:
We can just wrap the resulting domain Array in an arrow function so that it evaluates dynamically when the `Many2One` component mounts. Also added a unit test to explicitly cover this patched scenario. The test manually applies a local patch to `Many2OneReferenceField.prototype` to accurately replicate the environment and verify the fix.

opw-6563954

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

Closing a session fails with an unbalanced journal entry when it holds the refund of an order whose global discount falls on a specific rounding.

Steps to reproduce:
- configure a 20% tax and sell 2 x 2.12 in the PoS
- apply a 10% global discount, pay the order, then refund it
- close the session

The tax of the discount line cannot be recomputed from its price: the UI splits the rounded tax included amount, 0.51 here, into 0.42 of base and 0.09 of tax, where 0.42 taxed at 20% would give 0.08. It pins both amounts in 'extra_tax_data' with the quantity they were computed for, and they are used again only if the line still matches that snapshot. Refund orders reverse that quantity, so the discount line the UI builds for them no longer matches and its taxes are computed again.

Reverse those amounts only when the quantity they were computed for has the opposite sign to the one now used. Refunds made with "Return Products" copy the line with its quantity already negated, so reversing them as well would break those instead.

opw-6533657

Currently, when the user tries to produce a Manufacturing Order after generating a lot and increasing the quantity, they get a user error stating that a lot must be assigned.

## Steps to produce:
- Install Manufacturing
- Go to the setting enable Lots & Serial Numbers and Storage Locations
- Create a product 'Soda can' which is tracked by lots
- Create a bill of material for Soda can with component as 'Metal sheet'
- Create a storage location called 'Fridge' with parent location WH/Stock
- Create a Putaway rule for the Soda can to be stored in the fridge when it arrives in WH/Stock.
- Create and confirm a Manufacturing Order for soda can
- Click 'Generate Lot'
- Increase the total quantity to be produced from 1 -> 2
- Click 'Produce All'

## Observed Behaviour:
```
Invalid Operation:
You need to supply a Lot/Serial Number for product:
- Soda can
```
## Root cause:
When the user confirms the Manufacturing Order, `_apply_putaway_strategy` is called through:
``action_confirm -> _action_assign -> _apply_putaway_strategy``

This happens for both finished-product move lines and component-product move lines.

It updates the finished product move lines' destination location to `WH/Stock/Fridge` at:
https://github.com/odoo/odoo/blob/fd06c4df5889e23cfb701c12d743b5652141a111/addons/stock/models/stock_move_line.py#L288-L292

However, the `move_finished_ids` destination location remains` WH/Stock`.

After the user generates a lot and increases the production quantity using the wizard, `change_prod_qty()` updates the finished move's demand and re-reserves it through `_update_finished_moves()`:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L77

This calls `_action_assign` on the finished move:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L49

Within `_action_assign` because finished moves originate from the production location, they bypass the normal reservation logic at: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2086

So `_action_assign() `then tries to reuse an existing move line. However, it only searches for move lines whose `location_dest_id` matches the move's destination location
(WH/Stock):
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2108-L2117

The existing move line has `WH/Stock/Fridge` as its destination, so it does not match. As a result, a new move line is created for the finished move: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2182

The new move line gets the lot value from the Manufacturing Order: https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/models/stock_move.py#L557

Later, when Produce All is triggered,` button_mark_done()` calls` _post_inventory()`:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L2236

Because the finished move already has a `lot_id`, the condition below is not satisfied:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L1929-L1933

Therefore, the `lot_id` is not assigned to the move line that was created earlier.

When `button_mark_done()` validates the finished move lines, it finds that one move line has no lot assigned and raises an 'Invalid Operation' error.

## Solution:
Allow the user to produce the Manufacturing Order after changing the quantity. Increasing the quantity is a valid operation, so the user should not be blocked from completing the production afterward.

opw-6563498

**Steps to Reproduce**

- Install the `Documents` and `Project` modules.
- Create two companies.
- Create a project using the `Kanban quick create` option, without setting a company.
- A related workspace is automatically created without a company.
- Set a company on the project from the form view.
- The company of the related workspace remains unset.

**Observation**
- Projects created through the Kanban quick-create flow do not have a company assigned at creation time, so their related workspace is also created without a company.
- When the project's company is subsequently changed from the form view, the workspace company  was not updated. As a result, the workspace and its documents remained without a company.

**Solution**
When a project's company is changed, all projects linked to the same workspace are checked:
* If all projects belong to the same company, the workspace company is updated accordingly.
* If the linked projects belong to different companies and the workspace has no company, the workspace remain unchanged and accessible to all companies.
* If the linked projects belong to different companies and the workspace already has a company, an error is raised, preserving the existing behavior.

Backport of https://github.com/odoo/enterprise/pull/111760

OPW-6487090

### Steps to Reproduce:
1. Duplicate an Inventory Location so that you have one that is NOT a sublocation of any other location
2. Go to the Barcode module and click "Add Product"
3. Choose a product
4. For the location, select the new location
5. Click Confirm and observe the Traceback

### Issue:
In the Barcode module, selecting a location that falls outside the stock locations hierarchy causes a traceback. The initial frontend cache is designed to only preload sublocations of the primary stock location. When a user selects an un-cached location, the subsequent quant data fetch assumes the location is already cached and omits it from the payload, which causes an `UncaughtPromiseError` when the UI attempts to rebuild.

### Solution:
We can update `get_stock_barcode_data_records` in `stock.quant` to explicitly include the `stock.location` data in the returned payload. This mirrors how products and lots are handled, ensuring the frontend always receives the necessary location records even if they were excluded from the initial startup cache.

opw-6469721

Issue:
On off-cycle payslips for fixed-wage employees using attendance-based work entries, the Attendance worked-days line could show the full contract wage instead of a prorated amount.

Steps to reproduce:
- Configure a fixed-wage employee whose work entries are based on attendances.
- Create an attendance for only part of the payslip period.
- Go to Payroll > Payslips > Payslips.
- Click New Off-Cycle, select the employee, and open the Worked Days tab.
- Check the Attendance line amount and notice the full wage is being displayed not the amount of days worked only.

Cause:
In https://github.com/odoo/enterprise/blob/76d0d595054c0bbe764b83dcab7be078e7d0bf56/hr_payroll/models/hr_payslip_worked_days.py#L39-L56 `hr.payslip.worked_days._compute_amount()` computed the fixed-wage hourly rate by dividing the contract wage by the non-extra worked-day hours already present on the payslip. For attendance based payslips, those hours are actual attendances, not the expected working hours of the period.

With a single 8-hour Attendance line, the formula became: `contract_wage / 8 * 8` so the line amount incorrectly matched the full wage.

Solution:
For fixed-wage payslips, We need to compute the hourly rate from the employee's expected calendar hours for the payslip period, then apply that rate to the actual worked-day line hours. Keeping hourly contracts unchanged.

opw-6382337

## Short functional explanation of the error
When an employee doesn't have an active version, and they're on a leave considered working time. When we run the scheduled action `Attendance: Automatically check-out employees`, the employee is checked out after the defined tolerance time. The employee shouldn't be checked out, as they're considered working at the time.

## Reproduction steps
1. Create an employee without contract.
2. Go to Attendances > Configuration > Settings. Check Automatic Check-out. Select based on Tolerance and set the Tolerance at 2 hours.
3. Go to Time off > Management > Allocations and click on New. As Time Type, select a type considered as Working (like Homeworking or Attendance), set your employee and an Allocation duration. Click Validate.
4. Click on Management tab > Time off. Click on New and use for Time Type and Employee fields the same values you used on the allocation. Set the date as today.
5. Go to Attendances and click on New. Select the employee you're working with. Set the Check in at today, 3 hours before your local time. Remove the check out.
6. Enable the debugger and go to Scheduled Actions. Search for `Attendance: Automatically check-out employees` and click on Run manually.
7. Go back to Attendances.

### Expected Behavior
The attendance of the employee is still ongoing as they're on a leave considered as working time.

### Unexpected Behavior
The attendance of the employee has ended, and its duration is equal to the tolerance time defined in the settings.

## Origin of the issue
This bug doesn't occur when an employee has an active version, as we retrieve the work intervals taking into account the leaves of the employee:
https://github.com/odoo/odoo/blob/50298287733ce4ed8c5372495778e69cac5e114d/addons/hr/models/hr_employee.py#L1804 However, we don't take such leaves in consideration when an employee doesn't have a version:
https://github.com/odoo/odoo/blob/50298287733ce4ed8c5372495778e69cac5e114d/addons/hr/models/hr_employee.py#L1780-L1788

__
task-6453044

A user configured with "Officer: Manage all attendances" but no access to the Employees app can see the "Employees" entry under Attendances > Overview, since that menu only requires Attendance rights. Opening it, however, raises an access error naming the "Current Time Off Type" field.

Steps to reproduce:
-------------------
* Go to Settings > Users, open a user and set their access rights to: Employees app: no access, Attendances app: "Officer: Manage all attendances"
* Log in as that user
* Go to Attendances > Overview > Employees

> Observation:
Error:
"You do not have enough rights to access the field "current_leave_id" on Employee (hr.employee). Please contact your system administrator."

Why the fix:
------------
The "Employees" menu pointed to `hr.open_view_employee_list_my`, the full HR Employees action (model `hr.employee`, no view_id override), which resolves to the same default kanban view used by the Employees app. That view is extended by hr_holidays to embed `current_leave_id` (and other Time Off fields), declared with `groups="hr.group_hr_user"` on the model. That group restriction is enforced by the ORM on read, independently of whether the field is actually shown in the view, so any attendance-only officer opening the menu had that read rejected outright.

The menu now points to `hr_employee_attendance_action_kanban`, an attendance-scoped action already shipped in the module for this exact purpose: it uses the `hr.employee.public` model with a minimal kanban view (name, avatar, job, work location, check-in state), none of which require HR app access, restoring the ability to browse employees from the Attendance app without needing `hr.group_hr_user`.

opw-6488582

Problem: When a time off type is configured to require a supporting document, the system should prevent users from submitting a request without one.

However, users could bypass this requirement by creating and saving a request without uploading a file. Because the validation was not strictly enforced during creation or subsequent write operations, requests could enter or remain in active states without the mandatory documentation.

Solution: This commit ensures the system enforces mandatory attachments during the modification of time off requests that require a supporting document. The system now evaluates state transitions to block undocumented submissions.

Steps to reproduce(runbot v19):
1. Go to Time Off > Configuration > Time Off Types, create a new leave type and enable the "Allow To Attach Supporting Document" setting.
2. Create a new time off request for this type, leave the attachment empty, and save.
3. Notice that the system allows the invalid request to be saved and persist in the database without a document.

opw-6413621

After a recent change, the smart button for Source POs uses the reference_ids on a stock.picking. This altered the logic to fetch all orders from any picking that has the same reference. However, `subcontracting_source_purchase_count` should specifically relate to the resupply of subcontractor picking to their subcontracted purchase order.

**Steps to Reproduce:**
1. Enable multi-step routes and subcontracting
2. Unarchive the MTO route
3. Create 4 products Finished Product, A, B, C, and set MTO on both A and B
4. Put 10 units of C in stock
5. Create a BoM for Finished Product using A and B as components
6. Create a subcontracted BoM for B using C as a component
7. Set the purchase vendor for product A as the vendor
8. Set the purchase vendor for product B as the subcontractor
9. Create and confirm a manufacturing order for Finished Product
10. Confirm the POs

The two POs are:
1. Purchase Product A from its vendor
2. Subcontract Product B from its subcontractor and use Product C as a component

**Current Functionality:**
- Product A's receipt has a **Source PO** smart button pointing to the subcontracting PO for Product B (BUG)
- Product B's receipt has a **Source PO** smart button pointing to its own PO (BUG)
- Product C's picking has a **Source PO** smart button pointing to its own PO

**New functionality:**
- Product A's receipt has no **Source PO** smart button
- Product B's receipt has no **Source PO** smart button
- Product C's receipt has a **Source PO** smart button pointing to its own PO

opw-6420168

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Forward-Port-Of: odoo/enterprise#132030
Forward-Port-Of: odoo/enterprise#88495

In the `hr` addon, the `hr.employee` model defines `contract_type_id` and `structure_type_id` as `related` to the corresponding fields on the version of the employee. This is a related, `store=False` declaration.

The `hr_payroll` module redefines these two fields as related, `store=True`. Since the `version_id` field is computed and context dependent, this is a bug, which makes it impossible to read the correct value on the employee form view when switching between versions where the contract type or the structure changes.

We fix this by removing the `store=True` override in the payroll module.

Steps to reproduce:

0. setup: install `hr_payroll`
1. create an employee, with a contract that has a given contract type.
2. create a new version of the employee, changing the contract type in the new version

Observed behavior:
* when looking at the versions, we see the different contract type
* when looking at the employee form view, switching between the versions with the widget always show the same value for the contract type.

With the fix applied, we get the same behavior as with hr installed without hr_payroll.

Odoo support request: #6430012