Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#263064
Forward-Port-Of: odoo/odoo#249793

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#262665
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Problem:
The abandoned cart reminder can crash when Click & Collect is enabled. The stock availability check reaches website_sale_collect._get_product_available_qty(), which assumes request.cart always exists.

Solution:
Safely access the cart with hasattr and fall back to the existing no-cart behavior when it is unavailable.

Why:
Scheduled actions may have a request object without a frontend cart. This fix prevents the cron from failing while sending abandoned cart reminders.

Reproduction Steps:
- Configure the website with a warehouse.
- Create/publish a delivery method with delivery type “Pick up in store”. Confirm the website has both
warehouse_id and in_store_dm_id
- Create a cart from the website shop using a storable product that has does not have "Sell When Out of Stock" turned on.
- Leave the cart without checking out.
-  On the generated quotation set the date to the past, but also the date must be after the website.send_abandoned_cart_email_activation_time
- Run the abandoned cart reminder scheduled action for the eligible abandoned cart with a storable product.

Related Ticket:
opw-6133986

Related PR:
https://github.com/odoo/odoo/pull/242864

Forward-Port-Of: odoo/odoo#261885

Issue:
---
In `tax included` companies, the down payment section is not correctly calculated.

Steps to reproduce:
- Configure selected company's field account_price_include to be "tax_included"
- Create a sales order
- Create 1 or more down payment invoices for the SO and confirm
- Create a final invoice that pays for the rest of it
- On this final invoice where the down payment(s) are also listed, click on the preview button

Current behavior:
- The down payment section's total is the sum of the subtotal

Expected behavior:
- The down payment section's total should be the sum of the totals

Justification:
---
The amounts included in the invoice report are dependent on the
`company_price_include` field in `res.partner`. If tax_excluded,
subtotals are listed. If `tax_included`, totals are listed.
There was a mismatch between the entries and the section total;
the section entries could have the total as the amount while
the section's sum would be in terms of subtotals.

Fix:
---
On stable we can still rely on `section_subtotal` but set its
amount to total instead of subtotal in case of `tax_included`.

However, this fix is not stable as there is a xpath on `t-set`
expression in `l10n_ar`.
To avoid breaking the views, we can re-set the `section_subtotal`
in the next lines.
This would still cause issues as it will replace the overridden
logic in the `l10n_ar` implementation.
To prevent that issue, we can re-set the `section_subtotal` only
if the value is the same as `get_section_subtotal`, which means
we are in the main implementation and it's safe to re-set the value.

opw-6127615

Forward-Port-Of: odoo/odoo#262364
Forward-Port-Of: odoo/odoo#261372

## Fix 1

Steps to reproduce:
- create a time off type
- create a leave for that type and validate it
- go on the time off type record and try to change the request unit
- an error related to the leave is raised

Before this PR, it was not prevented to change the request unit
for time off types once leaves of that time off type were already taken,
leading to an error.

After this PR, `request_unit` now can be changed in the settings with
existing validated leaves without having an error raised. The leaves that
were previously created will not have their value recomputed based on the
new granularity for historical purposes.

This PR also removes an unused depends on
`_compute_dashboard_warning_message`.

## Fix 2

Before this PR, it was possible to have overlapping leaves:
(For time types that do not allow requests on top)
- Create a leave A and refuse it
- Create another leave B
- Validate B
- Validate A

This overlap should be caught and prevented by a constraint but currently isn't.

This PR adds the state to the dependencies to exclude the check on
refused/cancelled leaves but ensure that they cannot be validated if they overlap
other non-refused/cancelled leaves.

task-6153055

Forward-Port-Of: odoo/odoo#261036

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Forward-Port-Of: odoo/odoo#263200
Forward-Port-Of: odoo/odoo#261521

### Issue before this commit:
Sales taxes at 7% and 5% were incorrectly mapped to the same tax report  tags as the 18% sales taxes, causing them to be reported under the  'Taxable Goods/Services at 18%' line. In addition, the 7% and 5% report  lines displayed negative amounts instead of positive ones.

### Steps to reproduce the issue:
1. Install l10n_mt
2. Create invoices using 18%, 7%, 5% taxes
3. Go to Accounting > Reporting > Tax Report
4. See the amounts for Taxable Goods/Services at 18% is negative and  all the invoices are reported into the Taxable Goods/Services at 18%  even if the tax applied to the invoice is 5% or 7%

### Cause of the issue:
An automatic script (https://github.com/odoo/odoo/pull/225252)  missed to invert sign of formulas for the 7% and 5% lines, so their  values were displayed with the wrong sign. Moreover it is assigned to  the 7% and 5% Malta sales taxes the III.1_base  and III.1_tax tags, which belong to the 18% tax report line.

### Reason to introduce the fix:
The tag mapping must match the tax report structure so that 18%, 7%, and 5% sales taxes are reported in their respective lines. The report formulas for the 7% and 5% lines must also use the proper sign convention to display positive amounts consistently.

opw-6015509

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

Forward-Port-Of: odoo/odoo#263073
Forward-Port-Of: odoo/odoo#254894

On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from.

Steps to reproduce:
===================
1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains.
2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2).
3. From W2, submit a ticket on /helpdesk/helpdesk2.
4. In the ticket, send email from the chatter.
5. Inspect the outgoing notification email.

=> "View Ticket" button points to W1's domain.

Root cause:
============
`helpdesk.ticket` has no `website_id`, so `Base.get_base_url`
 falls through to `company_id.website_id.domain`, i.e. the first
website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in.

Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from.

=> "View Ticket" button points to W2's domain (the site the
   customer is browsing).

opw-6071999

Forward-Port-Of: odoo/enterprise#116034
Forward-Port-Of: odoo/enterprise#114693

During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them.

But since (https://github.com/odoo/odoo/pull/172714), the template uses `use_default_to` == True, which will compute the default partner and add them to `partner_ids` of the `mail.mail` record.

So the old bug of "abandoned cart email is sent twice" reappered: the if condition fails to account for `use_default_to` being set, so the partner email is set explicitly on `email_to` AND referenced in `partner_ids`, which de-facto sends the email twice to the customer on the sales order.

## FIX:
We account for `use_default_to` in the if condition before adding the fallback.

How to reproduce:
1) Setup a database with demo data and website_sale 
2) Visit the shop as a visitor, add stuff to your cart 
3) Sign up for portal access and add new stuff to cart (will attribute SO to new portal account)
4) Wait for the abandoned cart email to trigger (can be forced by playing with `cart_recovery_email_sent`: false,`is_abandoned_cart`: true and triggering the CRON) -> mail is sent twice to the customer

Remarks:
- changed the unit test to actually capture the generated `mail.mail` and apply some asserts on it

OPW-6134731

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

Forward-Port-Of: odoo/odoo#261039

Step to reproduce:
- install "purchase_stock" and "point_of_sale"
- Create a product attribute -> Display Type: Radio Button
-> Variant Creation Mode: Never create variants
-> Add two attribute values, ensuring that one includes a 'is_custom' field.
- Create a product and assign this attribute to it.
- Enable the MTO (Make To Order) route.
- Add a vendor to the product.
- Create and confirm a POS order for this product. (add text for custom attr)
- Observe that a Purchase Order is generated automatically.

Observation:
- the PO does not have that text in description

Cause:
- After commit [1], `description_picking` became a computed field.
- Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`.
- That key is no longer used for this purpose, so the information is not propagated and the data is lost.

https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343

above code is removed following that commit

Fix:
- The description is computed for pos orders

[1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8

opw-5969378


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

Forward-Port-Of: odoo/odoo#262866
Forward-Port-Of: odoo/odoo#253231

When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots.

Steps to reproduce:
-------------------
* Create a product with Tracking by lots
* In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)"
* Create a quotation with the product and confirm it
* Validate the delivery
* In POS, settle the sale order from Quotation/Order
* When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes

> Observation:
Quantity doubled.

Why the fix:
------------
read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice.
We now use move lines from exactly one picking and filter by sale_line_id.

opw-6001585

Forward-Port-Of: odoo/odoo#262953
Forward-Port-Of: odoo/odoo#253539

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/c71db2444eab951cab7eb2e68f780f0e68a3edd0/addons/project/models/project_project.py#L1183-L1186

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

Forward-Port-Of: odoo/odoo#263152
Forward-Port-Of: odoo/odoo#258370

Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. 

When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. 
https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896

Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. 

Steps to reproduce on Runbot:
Create a product tracked by serial numbers.
Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line).
Create a delivery for 1 unit of our test product and mark it as todo.
Ensure that serial 001 is reserved.
Click the Barcode smart button and scan the barcode for serial 002.
Click the back button.
Observe that both serial numbers are shown on the picking. 
Refresh the page and observe only serial 002 is now shown. 

opw-6105740

Forward-Port-Of: odoo/enterprise#115491

**Problem:**
After importing records through the Import action, the list view that opens with the imported records does not inherit the context of the originating action. Column visibility and default values that depend on that context (e.g. `default_move_type` on the shared invoice list) end up wrong.

**Steps to reproduce:**
1. Go to Accounting → Customers → Invoices
2. Click "Favorites → Import records"
3. Upload a CSV containing at least one valid customer invoice row
4. Run the import and look at the "Imported records" list that opens

**Current behavior:**
The imported records list opens with an empty context. Columns rendered conditionally on `default_move_type` (invoice-type-specific columns on `account.view_invoice_tree`) are not shown as they are when opening the list from the menu, and records created from that list have no default move type.

**Expected behavior:**
The imported records list should open with the same context as the action the user started the import from (e.g.
`{ default_move_type: 'out_invoice' }` for customer invoices), so columns and defaults match the previous view.

**Cause of the issue:**
`openRecords()` in `import_action.js` builds the follow-up `ir.actions.act_window` but never forwards `this.model.context`. The model already holds the context passed through the import action's `params.context`, but it is dropped when the redirect action is dispatched, so the window action opens with an empty context.

**Fix:**
Forwarding the context the import was launched with keeps the user inside the same functional scope (invoice type, default partner, company, etc.) when they land on the imported records list. Column visibility logic and default values that rely on that context behave identically to opening the list through the normal menu flow.

opw-6120758

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#261309

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

Forward-Port-Of: odoo/odoo#257849

Databases that are configured to have products be evaluated by lot and FIFO can experience weird behavior when the product's cost or `standard_price` is updated. The current code doesn't account for the fact that we allow users to dip into negative quantities and there aren't enough safeguards against this. This leads to the following bug that I found:

The FIFO algorithm can't be calculated when there is no quantity. Odoo uses a fallback cost whenever quantity is less than zero,  but this is incorrect when the product is evaluated by lots. Current behavior would calculate the fallback based on the product's standard price instead of the lot's standard price, leading to self-propagating calculation errors (e.g. cost going up to the trillions)

Videos of the bug:
Bug: ( Lot value defaults back to the product's standard price )
https://drive.google.com/file/d/1gUtjzdLpjeJts8HcxbTZ9MG4bSjRYmeT/view?usp=drive_link

Related tickets: opw-6011189

Forward-Port-Of: odoo/odoo#263127
Forward-Port-Of: odoo/odoo#256113