Commit 1
--------------
From the [commit], the options API was refactored to not use `OptionComponent` when
adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which
replaced the `OptionComponent` with some modified version. As the `OptionComponent` is
no longer present in the base option, patching the same won't use the modified option.
Hence, the option became visible in the mass mailing builder.

This commit adapts the mass mailing builder with the refactoring
of the options API to keep the image transform option hidden.

[commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99

Commit 2
-------------------    
### Steps to reproduce
1. Open Email Marketing
2. Open/Create a Mailing
3. In the editor, insert an `Alert` block.
--------> Some options won't be visible.

### Technical
The [commit] restructured the `Alert` snippet, therefore, for the builder to identify
the mass mailing's alert block, we need to adapt the selector of the option
to `.s_mail_alert`.

After this commit, the following options will become visible (which were invisible before
the commit):
- Background Color
- Border Option

Note:
1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template.
Which included different size options, but those are now already added by `size_option_plugin`.
Therefore this commit also removes those redudant size options from the alert option.

2. The width option for the `Alert` block is already added by original `width_option_plugin`,
therefore we remove the patch of the selector inside mass mailing to avoid redundancy.

[commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6

Task-5999942

Forward-Port-Of: odoo/odoo#260923

## Summary                                                                                                                                                                                                                           
                                  
  When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:                                         
                  
  ValueError: Expected singleton: uom.uom()                                                                                                                                                                                            
                  
  ## Root Cause                                                                                                                                                                                                                        
                                                                                                                                                                                                                                       
  The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:                                                                                 
                                                                                                                                                                                                                                       
  ```python                                                                                                                                                                                                                            
  empty_lines = open_sale_orders.order_line.filtered(
      lambda l: l.product_uom_id.is_zero(l.qty_delivered)                                                                                                                                                                              
  )                                                                                                                                                                                                                                    
   ```                                                                                                                                                                                                                                    
  This accesses product_uom_id without checking if it exists. Lines with:                                                                                                                                                              
  - display_type set (sections, notes)
  - is_downpayment = True (downpayments)                                                                                                                                                                                               
                                        
  ...don't have a product_id or product_uom_id, causing the error.                                                                                                                                                                     
                                                                                                                                                                                                                                       
  Fix                                                                                                                                                                                                                                  
                                                                                                                                                                                                                                       
  Add filters to skip non-stock lines before accessing product_uom_id:                                                                                                                                                                 
   ```               
  empty_lines = open_sale_orders.order_line.filtered(                                                                                                                                                                                  
      lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)                                                                                                                              
  )                                                                                                                                                                                                                                    
```
  Steps to Reproduce                                                                                                                                                                                                                   
                                                                                                                                                                                                                                       
  1. Create a fresh database (without sale_stock/purchase_stock)                                                                                                                                                                       
  2. Create a sale order with a downpayment line or section/note
  3. Install sale_stock module                                                                                                                                                                                                         
  4. Error: ValueError: Expected singleton: uom.uom()                                                                                                                                                                                  
                                                                                                                                                                                                                                       
  Reproduction Reference                                                                                                                                                                                                               
                                                                                                                                                                                                                                       
  - purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing                                                                                                                           
  - sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
                                                                                                                                                                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                       
  opw-6179073                                                                                                                            

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

Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload

Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.

Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6

When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.

Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format

`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons

opw-6064997

Forward-Port-Of: odoo/odoo#258829

**Issue:**
Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error:
```
The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding"
DETAIL:  Key (id)=(1919) is referenced from table "account_cash_rounding"
```

**Steps to reproduce:**
1) install l10n_be module
2) make a new belgium company
3) go to accounting > configurations
4) change the fiscal localization package to "Belgium- Associations and Foundations"

**Cause:**
`account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'`

**Solution:**
Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch.

opw-6165374

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

When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

Ticket [link](https://www.odoo.com/odoo/project.task/6148039)
opw-6148039

Forward-Port-Of: odoo/odoo#262339
Forward-Port-Of: odoo/odoo#261964

When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly.

Steps to produce:
---
- Install the `website_sale` module.
- Go to Settings and enable `Prevent Sale of Zero Priced Products`.
- Create a product with a sales price of `0` and publish it.
- Open the product on the website.
- Open the editor and change the purchase style to `Box`.

Issue:
---
- The price text renders incorrectly inside the box.

Root Cause:
---
- At [1], the `<span>` element responsible for rendering the price text does not check whether zero-price sale prevention is enabled, causing the price string to appear regardless.
- At [2], after hiding the price span, the `o_wsale_cta_wrapper` element still renders an empty box because no corresponding guard exists there either.

Solution:
---
- Add a conditional check on the price `<span>`: apply `d-none` when zero-price sale prevention is active, so the price string is not displayed.
- Also, add the same zero-price sale prevention check on `o_wsale_cta_wrapper` to avoid rendering an empty box when no price is shown.

[1]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2233
[2]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2221

Before:
---
<img width="1488" height="689" alt="image" src="https://github.com/user-attachments/assets/5b3a565f-5ced-4d75-b538-63abc3690e09" />

After:
---
<img width="1457" height="612" alt="image" src="https://github.com/user-attachments/assets/1e04fe54-98b6-4e1c-bd26-4d56bb34b90e" />

opw-5994812
---

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

Forward-Port-Of: odoo/odoo#261313
Forward-Port-Of: odoo/odoo#252666

**Steps to reproduce**:
- Activate analytic accounting on the settings
- Create an Analytic distribution models for a partner
- Create a product P with a cost and Inventory Valuation set to Perpetual
- Create a location L with a Location Type set to Inventory Loss and a Loss Account
- Create an internal transfer from Stock to location L for product P
- Confirm it
- Check the associated journal entry:
-> The analytic distribution is not set of the move lines

**Cause**:
While validating the picking:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock/models/stock_picking.py#L1426 An account move is created without specifying `partner_id`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L178 https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L200-L205 This leads to the creation of account move lines, triggering `_inverse_analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1416-L1417 The method accesses `analytic_distribution` of the `move_line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1410 which triggers its associate compute method:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1213

To retrieve the right `analytic_distribution`:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1224 By defining this search domain:
https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L85

if `partner_id` is not in the `vals`, it falls back to False: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L79 As a result, the distribution linked to the `partner_id!` is not found, since the `partner_id` of the vals is determined from the `account.move.line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1237 which is False since it is not specified while creating the account move.

opw-5918058

Forward-Port-Of: odoo/odoo#261713

## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**

## Cause
The condition to raise the error message does not take into account the state of the leave:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204

This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.

(related to)
opw-6089990

Forward-Port-Of: odoo/enterprise#115765

**Steps to reproduce:**
* Install `l10n_in` module.
* Go to Accounting > Settings.
* Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username
* Uncheck `Registered Under GST`.
* Try to modify any setting and save.

**Observed behavior:**
* A `Missing Required Fields` error is raised even though no visible field is missing a value.

**Cause:**
* The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`.
* However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`.
* Since both features default to enabled, the field remained required even when invisible, blocking any settings save.

**Fix:**
* Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled.

opw-6133001

Forward-Port-Of: odoo/enterprise#114423

### Issue:
When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly inflated, causing the sale to appear less profitable or even at a loss in the accounting records.

### Steps to reproduce:
1. Set a product as storable with FIFO costing and real-time valuation.
2. Create a Sale Order with two lines for the same product at different prices.
3. Confirm the SO and validate the two deliveries (each consumes a different FIFO layer).
4. Invoice the first SO line and post the invoice.
5. Invoice the second SO line and post the invoice.
6. Observe that the COGS on the second invoice is higher than the actual cost of the stock move linked to that line.

### Root Cause:
_get_cogs_qty() and _get_posted_cogs_value() in sale_stock filtered already-posted COGS lines by product_id. This caused them to aggregate quantities and values across ALL SO lines sharing the same product. However, _get_cogs_price_unit() derives the unit cost only from the current line's stock move. The mismatch results in:
  (unit_cost_of_line_2 * total_qty_of_both_lines) - cogs_already_posted

### Fix:
Replace the product_id filter with a sale-line-scoped filter using cogs_origin_id. By checking cogs_origin_id.sale_line_ids & sale_lines, only COGS originating from the same SO line(s) as the current invoice line are considered, correctly isolating each line's COGS from the others.

opw-6004810

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

Forward-Port-Of: odoo/odoo#257868

**Steps to reproduce:**
- Order a combo in the self order Mobile with multiple products
- Order the same combo more than once
- Checkout and go to the linked restaurant
- Go to the orders, the price is not the same as in the self
- If you check the unit prices in the backend, they are not consistent

**Why the fix:**

This is mostly a backport of bd117e8 with an addition because the extras still did not work as intended.

In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines.

This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 
But the total price has been computed to zero, so the previously computed price_unit is overridden and set to zero.

We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line.

The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation.

There was an oversight in the original fix, which meant that the unit prices were not distributed as they should have been, even though the total was correct. When we only order one combo that costs 25 and has 2 items, both items will have a price_unit of 12.5, but if we have more than 1 qty of said combo, the price_unit will be all over the place and the second item will have to compensate for the first one thanks to
https://github.com/odoo/odoo/blob/b108bb847b1c4d3a91f223d77a4888b8139b0a8d/addons/pos_self_order/models/pos_order.py#L322-L323

We now update the original total to take the fact that multiple combo can be ordered.

We replace the fix done by https://github.com/odoo/odoo/commit/0e0c5550b51db1e311b47ca523263868c7471dcd as it did not account for every situation, and was done at the same time as this commit.

opw-6076911

Forward-Port-Of: odoo/odoo#257922

### Steps to reproduce:

- Create and confirm an MO for 1 unit of product without bom
- Set the producing quantity to 1
- Add a new component line for a product tracked by SN
- Click on details operation and add a lot > Save
- Produce all
#### > The quantity is of the component move is reset to 0 and the lot erased

### Cause of the issue:

Setting the producing quantity to 1 will set the state of the of the MO to `to_close`. After which, adding a new move will add it in the appropriate `picked` state so that the move is considered when validating the MO:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/mrp/models/stock_move.py#L269-L270 
However, clicking on the detailed operation and selecting a lot will create a new `move_line` without set `picked`. As such the related picked compute method of the stock move will be launched:
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L123-L127
resetting the picked state of the move to False as a new move line was added (triggering a dependency of its compute method):
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L126
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move.py#L280-L286

Additional change:

The test `TestSubcontractingBasic.test_flow_tracked_1` underlined that the `auto_pick_move_lines` context key added to `action_show_details` had to be cleaned in subcontracting flows before synchronizing the subcontracted productions:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/mrp_subcontracting/models/stock_move_line.py#L34-L38
Otherwised, if a receipt for tracked subcontracted product is picked and additional move lines are added via the detailed operations, the subcontracted backorders created to fulfill the additional demand will will pick each of their move leading to subcontracted MO's that will avoid assignment:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L1914-L1916
and be cancelled at the picking validation:
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/mrp/models/mrp_production.py#L1924
https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L2107-L2109
This can be checked by launching the test without the `clean_context`.

We also improve the `TestSubcontractingBasic.test_flow_tracked_1` test as it is not possible to edit moves to be picked prior to confirmation and since move lines can not manually be created in picked state.

### Fix:

Note that we rely on a context key to adapt the compute method of the picked field of the `stock.move.line` instead of adding a `default_picked` context in the `action_show_details` because the new move lines added to the list view of the `move` form are generated via the UI by opening a list of `stock.quant` which cleans the `default_context` key prior to generation of the `new` move line. In particular, the exact UI flow can not be tested by relying on the `Form` class of stock moves since the new move lines will then be created by via the `O2MForm` class:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L642-L658
and an onchange of the stock move line will be triggered to determine its value relying on the `default_picked` context key to create the new move line in picked state:
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L332-L339
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L579
https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/addons/web/models/models.py#L2005-L2008
By contrast performing the flow from the interface will highlight that the `default_picked` context key does not solve the issue.

opw-5991985

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

Forward-Port-Of: odoo/odoo#258935

Steps to reproduce:
- Install documents_account and account_accountant.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
When attaching an image via a log note, the file becomes the main
attachment but is intentionally unlinked (res_model=False) by the
system to avoid UI clutter. Downstream modules unknowingly sync this
orphaned file. Later, when "Send & Print" generates the real PDF,
the system attempts to update the orphaned downstream record, causing
model linkage conflicts and eventually a crash.

Solution:
Add `no_document=True` to the context during `_message_post_after_hook`
for invoices. Previously, for incoming emails or log notes, the mail
framework would trigger document creation immediately before the core
accounting module could evaluate and orphan invalid files (like images).
This change suppresses that premature sync, allowing downstream modules
to explicitly handle the sync after the attachment's final state is
resolved.

opw-5930888

Forward-Port-Of: odoo/odoo#262344
Forward-Port-Of: odoo/odoo#258307

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888

Forward-Port-Of: odoo/enterprise#115881
Forward-Port-Of: odoo/enterprise#115065

Steps to reproduce
1. Install l10n_ar (or any LATAM localization).
2. Go to Accounting > Configuration > Journals and open a Purchase journal
   that has "Use Documents?" enabled.
3. Enable "Secure Posted Entries with Hash".
4. Create and post a vendor bill with a high document number (e.g. 00001-00009999).
5. Create another vendor bill with a lower document number (e.g. 00001-00000100)
   and try to post it.

Issue
Posting the second vendor bill fails with:
"This move could not be locked either because some move with the same sequence
prefix has a higher number. You may need to resequence it."

The hashing logic in account_journal.py enforces a strict continuous sequential
chain per journal:
https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678

In LATAM countries, vendor bill document numbers are assigned by the vendor, not
by Odoo. A bill with a lower number can legitimately be entered after one with a
higher number, which breaks the sequential assumption the hash chain relies on.
Allowing it would produce a hash that no longer represents a proper chain, giving
users a false sense of security. Sales journals are unaffected because Odoo
controls their sequence.

Solution
Hide the "Secure Posted Entries with Hash" field on purchase journals that have
"Use Documents?" enabled, preventing users from enabling an option that cannot
work correctly for vendor-assigned document numbers. Sales journals keep the
option available since Odoo controls their sequence.

opw-6076673

Forward-Port-Of: odoo/odoo#261664
Forward-Port-Of: odoo/odoo#259206

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115723
Forward-Port-Of: odoo/enterprise#114429

**Steps to produce:**
- Install `sale_management` without demo data.
- In settings > Under Taxes > Set `Tax Prices` as `Tax Included`.
- Create a product with a sales price of 10.
- Create a quotation with this product.
- Confirm the line amount shows 10 (tax included).
- Click on preview.

**Observation:**
- In the preview, the product line amount is shown as tax excluded.

**Root cause:**
- At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`.
- This logic is not applied in the portal preview and PDF report.

**Solution:**
- Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`.

[1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663

Before:
---
<img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" />

After:
---
<img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" />

opw-6089473
---

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

Forward-Port-Of: odoo/odoo#261892
Forward-Port-Of: odoo/odoo#258551

**Steps to reproduce:**
* Install `l10n_ar_withholding` module.
* Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%)
* Select 'Own Checks' within the payment method.
* Clear Withholding lines and add line with tax `IIBB WTH CABA`.
* In the Checks tab, input the check number, date, and amount (30000) natively.
* The computation of the withholding lines is triggered.

**Observed behavior:**
* The total gross amount registered computes to exactly $30,247.93 instead of mathematically converging to the true original invoice debt of $30,250.00.

**Cause:**
* The `l10n_ar_withholding` module uses an iterative mathematical solver to progressively bump `wizard.amount` upward to effortlessly offset and scale the equivalent proportionate withholding taxes accurately.
* However, inside Odoo's iterative memory loop (`for i in range(201)`), the ORM caches computed values across passes for NewId performance. As `wizard.amount` increments upwards, the dynamically dependent `l10n_ar_withholding_ids.base_amount` and `amount` fields fail to automatically invalidate their internal cache.
* The loop relies on these statically cached values (e.g., $247.93) to verify if equilibrium has been reached, wrongfully satisfying the balancing exit condition and halting the loop prematurely.

**Fix:**
* Recompute the `base_amount`, `amount` using `add_to_compute` on the `l10n_ar_withholding_ids` automatically inside the iterative loop in `account_payment_register.py`.
* This signals the ORM to cleanly dump the stale cache dependencies, natively forcing mathematically correct recalculations of the proportionate untaxed withholdings at every incremental `wizard.amount` step. The solver now strictly converges optimally to exactly block the correct value in 1-2 rapid passes without hanging on legacy computation artifacts.

opw-5934489

Forward-Port-Of: odoo/odoo#254635

Steps to reproduce-
1) In a multi-company environment, create an employee in a secondary company. 
2) Link a Portal User to this employee via the user_id field. 
3) Create and validate a payslip for this employee. 
4) Run the 'Payroll: Generate pdfs' cron.

Error - ValidationError: The following user(s) cannot own root documents/folders:
portal_employee: Payslip - portal_employee

Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company).

When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner.

Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies.

opw-6143042

Co-authored by Tina Lin (liti)

Forward-Port-Of: odoo/enterprise#115570