## [FIX] account_edi_ubl_cii: ensure base_vat

VAT validation is actually in base_vat which account does not depend on...
This test fails when it's not installed, it's just hiding a design problem
but it cannot be fixed in stable.

runbot-941422

## [FIX] account_edi_ubl_cii,account_peppol: move up default EAS validation
    
**Problem:**
When standard UBL BIS3/CII documents are generated, EAS schemes (such as the Australian
ABN) need to be formatted/space-stripped.
Previously, the normalization and validation of EAS routing identifiers via
as defined in the account_peppol module.
If the test database did not auto-install account_peppol (for example, in
non-European localization setups), the spaces in the ABN (e.g. 53 930 548 027)
were not stripped.

**Solution:**
Moved the account_peppol validation override up to account_edi_ubl_cii.

This guarantees that EAS values are properly cleaned and formatted during XML export
across all module installation combinations.

runbot-941422

### Description of the issue/feature this PR addresses:

- Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error.

- **Steps to reproduce:**

1. Open any form view (e.g., Contacts) and enter `Studio`.
2. Create a new `Many2many` custom field on a model such as `res.partner`.
3. Set the field's widget to `many2many_tags_email` and save the customization.
4. Exit Studio and populate the field with one or more related records.
5. Open Studio again on the same form view.

This results in the following error:
```.js
Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined
(should be a value)

```
### Current behavior before PR:

- When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag] component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an I nvalid props for component 'RecipientTag' error.

### Desired behavior after PR is merged:

- RecipientTag should allow onDelete to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available.

opw:6395209

[RecipientTag]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js

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

Forward-Port-Of: odoo/odoo#278252
Forward-Port-Of: odoo/odoo#277934

Problem:
When computing inventory valuation or available quantities for a date in the past (using the  context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date.

However, when the environment context specified an ownership filter (e.g.,  to calculate company-owned valuation), this filter was only being applied to the  domain. The rollback domains for incoming and outgoing  records remained completely open.

As a result, the system would correctly see 0 company-owned current stock, but it would erroneously subtract incoming consigned stock moves from that balance. This resulted in an artificially negative past quantity and a negative inventory valuation for company-owned stock.

Solution:
This commit ensures the  context is applied symmetrically by filtering the rollback moves via the  field. The
time-travel calculation will now only evaluate stock moves that match the queried ownership context.

Steps to reproduce (runbot v19):
- Consignment enabled
- FIFO perpetual product w/ nonzero value
1. Create an inventory adjustment for an internal location, set the owner on the quant
2. Create a delivery for this product, but don't zero out all of the available stock
3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, before any move history in the db. The product's current on hand value will appear in ending stock, but negative.

opw-6300582

Forward-Port-Of: odoo/odoo#274492
Forward-Port-Of: odoo/odoo#270409

**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#277021
Forward-Port-Of: odoo/odoo#275294

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Forward-Port-Of: odoo/odoo#277822
Forward-Port-Of: odoo/odoo#276861

Steps to produce: 

1) Install Manufacturing & enable "Work Order Dependencies" in the settings
2) Make a new BOM with 2 operations
3) Check "Operation Dependencies" in the miscellaneous tab on the BOM's form view.
4) Configure the first sequential operation to be blocked by the second
5) Make and confirm an MO using this BOM
6) Uncheck "Operation Dependencies" on the BOM
7) Press "Plan" on the MO, a validation error is thrown stating "You cannot create cyclic dependency."

Issue occurs because after the MO is confirmed the blocked_by_workorder_ids field for mrp.workorder records is set based on the order manually configured on the BOM (operation 1 is blocked by operation 2). After the BOM is edited to have allow_operation_dependencies = false, then Odoo uses the default sequential ordering when planning the operations (operation 2 is blocked by operation 1). Since the old ordering is never cleared, a cycle is created unintentionally. 

This PR resolves this issue by clearing the blocked_by_workorder_ids field on mrp.workorder records. 

opw-6334271

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

Forward-Port-Of: odoo/odoo#277843
Forward-Port-Of: odoo/odoo#275154

**Problem:**
For an hour-based time off allocation, changing the employee's working schedule leaves the allocation duration (in days) stale, so the balance shown on the Time Off dashboard becomes wrong.

**Steps to reproduce:**
1. Give an employee a working schedule of 8 hours/day.
2. Create an hour-based allocation (time off type with Request Unit = Hours) granting e.g. 8 hours (1 day).
3. Change the employee's working schedule to one with a different Hours per Day (e.g. 4 hours/day).
4. Check the allocation / the Time Off dashboard balance.

**Current behavior:**
number_of_days stays at its old value (1), so the balance is recomputed as 1 day x 4 hours = 4 hours instead of the 8 hours actually accrued.

**Expected behavior:**
The accrued hours stay constant; the duration in days follows the new schedule (8 hours / 4 hours-per-day = 2 days).

**Cause of the issue:**
`number_of_days` and `number_of_hours_display` compute from each other (`number_of_days = number_of_hours_display / hours_per_day` and `number_of_hours_display = number_of_days * hours_per_day`), forming a dependency cycle, and neither depends on the employee's working schedule. So a schedule change never recomputes either field. Adding the schedule to `_compute_number_of_days`' depends does not help: because of the cycle it recomputes `number_of_hours_display` from the stale `number_of_days` first, which silently destroys the accrued hours.

**Fix:**
When the employee's working schedule changes, the accrued hours are the quantity that must be preserved, so the duration is recomputed explicitly from the still-stored `number_of_hours_display` (setting `number_of_days` first, exactly as a manual `_compute_number_of_days()` does). Driving the order by hand is necessary because the cyclic compute graph cannot guarantee `number_of_days` is computed before `number_of_hours_display`.

opw-6276242

Forward-Port-Of: odoo/odoo#270129

[FIX] html_builder: fix job location editing on website
Scenario:
1) Head over to website
2) Go to any specific job page
3) Open editor
4) Try changing job location
5) Hit save

Result: The changes aren't saved or propagated into the backend.

Expectation: Users should be able to edit job locations via the
editor on website and have those changes reflect on the site
and job record.

Cause:
How elements were marked as savable was changed [in this IMP][1] to
rely on `o_savable` rather than the savable selectors resource. As a
result, elements which had the `o_not_editable` class, such as job
location, did not have `o_savable` added to them. These elements were
excluded from the builder's dirty-tracking for save. Therefore, editing
the location didn't mark the element as changed and saving to drop the
update.

Fix:
Remove `o_not_editable` from the location element on plugin setup so
the field is now editable and savable through the builder option.

This surfaced a second issue: when the location was set to "Remote",
the element's content could be directly editable inline. Saving it
that way disconnected the content from the job location field. This
was fixed by adjusting the selector that determines when a many2one's
content is editable inline. The result is the "Remote" case is handled
consistently as changing to any other location.

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

Task-6311200

*: stock_landed_costs, purchase_{stock,mrp}, stock_dropshipping, sale_mrp, pos_mrp, repair, mrp_landed_costs, mrp_subcontracting_{dropshipping,landed_costs}, point_of_sale, {project_,}stock_account

Adapts the test skipped to fast merge the valuation refactoring made in https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229.

<img width="482" height="297" alt="table" src="https://github.com/user-attachments/assets/ba57f350-2a9e-4a51-990d-fabe14f5a56a" />

 (*) Includes the one sale_project_stock_account test re-enabled through the TestAnalytics subclass.

It is organised as one commit per module. Two of the re-enabled tests surfaced genuine bugs in the new valuation model; those commits also carry the related fixes: purchase_mrp, project_stock_account Every other commit changes tests-only.

Only one skipped test remains: point_of_sale TestUi.test_05_ticket_screen, a browser tour with no stock-valuation content that was swept into the mass skip by mistake and fails for an unrelated reason (it is left to a separate point-of-sale tour investigation).

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

Forward-Port-Of: odoo/odoo#275246

**Issue**
A credit note created before returning any stock may compute an incorrect COGS value.

**Steps to reproduce**
- Create a product valued with AVCO and a standard price of 10
- Create and confirm a SO for 2 units
- Create and post the invoice
- Change the product's standard price to 20.
- Create a credit note without returning the delivered stock
-> The cogs value on the credit note is 40 instead of 20

**Cause**
While posting the credit note:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale/models/account_move.py#L62
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/account/models/account_move.py#L5580
COGS lines are created:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L46
which needs to compute the unit_price:
https://github.com/odoo/odoo/blob/f715337f70bf7eaa8f084da6cd42d674d7a4bfe0/addons/stock_account/models/account_move.py#L132
which is initially computed from the original invoice line:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L308-L317
However, the `sale_stock` override recomputes that value whenever the invoice line is linked to a sales order:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L173
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L212-L213
This computation will give the standard price since:
- `is_returned` is True but no return move, which means there won't be any candidate:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L921-L923
- As a result, `qty_valued` is zero:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L933-L936
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/stock_valuation_layer.py#L172-L173
- The computation therefore falls back to the current standard price:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L938-L946

opw-6369550

Forward-Port-Of: odoo/odoo#276926

When searching on the Website site, using the main search on the navbar, it opens a list view with the results (`website.list_hybrid`) which raises the warning on the logs (2 times):
"Unknown directives or unused attributes: {'t-key'} in website.list_hybrid"

![Task 79454 - Issue 434 - Image of Warnings](https://github.com/user-attachments/assets/f5a3100b-c617-4c38-a8b5-f42427a4317c)

This happens after the attribute `t-key` was added to the template [\[1\]] because the template is only used in QWeb. The validation for them doesn't include the `t-key` [\[2\]] as one of the "iter_directives" nor has a `_compile_directive_*` method to check and remove it from the validation as it's done with the `t-as` and `t-foreach`.

This also causes the raise of the warnings on tours that use the tour method `searchProduct` (of the module `website_sale`) because it uses the first input with the name of search and happens to be the search on the navbar.

![Task 79454 - Issue 434 - Search Input](https://github.com/user-attachments/assets/923f5d63-5cfb-4c0b-a563-0eabc04882bb)

[\[1\]]: https://github.com/odoo/odoo/commit/7b1d82aa
[\[2\]]: https://github.com/odoo/odoo/blob/f52cfb09/odoo/addons/base/models/ir_qweb.py#L1400

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

Forward-Port-Of: odoo/odoo#179017

Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`.

Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund`  with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound".

As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts.

This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document`

opw-6373124



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

Forward-Port-Of: odoo/odoo#276846

### Issue before this commit:
When importing an electronic invoice from SDI that is failing with an exception, the resulting account.move record was saved in the "Miscellaneous Operations" journal instead of the correct one (Vendor Bills), even though the move_type itself was correct.

### Steps to reproduce the issue:
Pre steps: you need to have access to https://iap-services-test.odoo.com/odoo
1. Download Accounting and l10n_it
2. Go to Settings > Companies and set the VAT of IT company the same as the one in the xml
3. Go to Settings > Italian Electronic Invoicing and select Test
4. Go into the code and insert an Exception inside the function _l10n_it_edi_import_invoice after self.move_type = move_type (or create any type of exception from the user interface)
5. Go to IAP service into IT EDI app and see that your company is there as user
6. Click into the record > receive move button > upload your xml > create
7. Go to your DB > Scheduled Actions > filter with IT > IT EDI: Receive invoices from the SdI > Run Manually
8. Go to Journal entries, remove the filter and find your imported bill
9. You can see it was inserted into the Miscellaneous Operations Journal instead of a Vendor Bill Journal

### Cause of the issue:
The move is created inside a savepoint context manager, designed so that even if parsing fails, an empty move with the attachment still remains. The problem is that if the exception is raised, the savepoint rollback undoes everything that follows, but the journal was already determined before the correct move_type was known, leaving the move in the wrong default journal.

### Reason to introduce the fix:
The fix is needed to ensure that, regardless of where parsing fails, the move's journal is correctly set even if an exception occurs so that it is possible to find the move in the correct section even if not imported correctly.

opw-6397712

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

Forward-Port-Of: odoo/odoo#278472
Forward-Port-Of: odoo/odoo#278111

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#276289
Forward-Port-Of: odoo/odoo#276211

**Description of the issue/feature this PR addresses:**

[FIX] website_sale: preserve parent company link on address update

When a portal user linked to a company (B2B) edits their address during
website checkout, the backend partner form subsequently loses the visual
link to their parent company and incorrectly displays a "Create company"
button instead.

This occurs because the checkout form submits the company name as a raw
text string (`company_name`). This string gets passed in the payload and
is written to the contact's record. In the backend `res.partner` form
view, the presence of data in the `company_name` field triggers UI
modifiers that hide the `parent_id` relational field and switch to the
B2C company creation flow.

This commit resolves the issue by conditionally removing `company_name`
from the payload if the user already has a `parent_id`. This ensures the
raw text is safely ignored for B2B users, keeping the backend UI intact
while preserving the expected behavior for unlinked B2C users.

opw-6374326

**Steps to Reproduce:**

- Contacts > New
  - Set type to “Company”, any name, any Tax ID
  - (On same page) > Contacts & Addresses > Add
    - Set type to “Contact”, set any name/email
- Access the previously created (individual) contact > settings/gear icon > grant portal access > Grant Access
- Access the (individual) contact user form > settings/gear icon > Change Password > (any)
- Log in as portal user > add item to cart > checkout > Modify address and save
- Access the created (individual) contact again
  - Observe “Create company” button despite partner_id being set. In addition, the company name is shown correctly, but no link appears


**Current behavior before PR:**

- When a portal user linked to a company edits their address during website checkout, the backend partner form stores the company_name field and hides the link to the parent company while displaying a "Create company" button

**Desired behavior after PR is merged:**

- Portal users linked to a company should be able to edit their address without losing UI links to the parent company in the partner form

Forward-Port-Of: odoo/odoo#275468