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

Given
https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90

Then `test_import_product_demo_xls` incorrectly pairs .xls file extension with mime type `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`

### Current behavior before PR:

Tests in the product module fail when openpyxl is installed.

```
2025-05-19 15:08:32,243 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.supplierinfo]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
 
2025-05-19 15:08:32,268 1 WARNING odoo odoo.addons.base_import.models.base_import: Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'). 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 429, in _read_file
    return getattr(self, '_read_' + file_extension)(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 509, in _read_xlsx
    book = load_workbook(io.BytesIO(self.file or b''), data_only=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 344, in load_workbook
    reader = ExcelReader(filename, read_only, keep_vba,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 123, in __init__
    self.archive = _validate_archive(fn)
                   ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 95, in _validate_archive
    archive = ZipFile(filename, 'r')
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1349, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1416, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
2025-05-19 15:08:32,269 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.template]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
```

### Desired behavior after PR is merged:

Tests pass even when openpyxl is installed.

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

…compute

**PROBLEM**
When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one.

**STEPS TO REPRODUCE**
1. On a fresh database, install stock with drop shipping and storage locations enabled.
2. Create a new operation type and set the type to Delivery.
3. You will receive the following warning, despite an existing warehouse:

```
Please create a warehouse for company <company>
```

**CAUSE**
https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316

https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74

When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed.

Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False.

**FIX**
In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`.

opw-4603495

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

When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
  Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button

Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
    return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```

https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.

sentry-6620429585

…followers

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

Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only portal users have access.

**Current behavior before PR:**
The 'follower' group in _notify_get_recipients_groups is being explicitly marked with 'has_button_access': True. Therefore followers without portal access are having access to the button.

**Steps to reproduce:**

1. Configure odoo to be able to send out emails.
2. Install sale_management.
3. Create a sale order for a customer and add as follower another partner that has no portal access. This follower needs to have an email you have access to.
4. Send a message to the follower.
5. Test in the received email that the "View Quotation/Order" button is shown and when clicked, the user is redirected to the login page.

**Desired behavior after PR is merged:**
Only followers with portal access will have access to the button.

Note that followers with portal access are directly categorized as 'portal_customer', so that is why it would make sense to simply remove the code where the followers without portal access are given access to the button.





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

Forward-Port-Of: odoo/odoo#210343
Forward-Port-Of: odoo/odoo#208402

When creating an inter-wh transfer, the replenish order was showing the product's supplier in the Received From (partner_id) field and not the correct wh.

Steps to reproduce:
-------------------
* In Inventory, activate Multi-step Routes
* Create a new WH that can be Resupplied From another WH
* On a product, in the Inventory tab, activate the Route 'ABC: Supply Product from XYZ'
* On the forecast of that product, click on Replenish
* Match fields: Warehouse = ABC, Preferred Route = 'ABC: Supply Product from XYZ'
* Confirm
* Open the generated order

> Observation:
> The field Receive From contains the supplier of the product instead of the supplying WH.

Why the fix:
------------
The supplier_id was automatically set with the product's supplier_id. It's not correct for every routes. It's now updated accordingly to the route used and if we need the vendor.

opw-4717654


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

Forward-Port-Of: odoo/odoo#210336

[FIX] website: update sitemap lastmod on website page view changes

Before this commit, since the introduction of the website page model at
commit [1], the lastmod for pages indicated in the sitemap was not
entirely accurate: it only considered *page record* changes, not their
internal *view changes*.

Steps to reproduce:
- Create a new website page and publish it
- Go to /sitemap.xml, see the page is mentioned with correct lastmod
- Wait for one day **
- Update the page URL
- Go to /sitemap.xml, see the lastmod was updated
- Wait for one day **
- Update the page content
- Go to /sitemap.xml
=> The lastmod was unchanged

**: the lastmod does not show the hours. You will need to update the
    write_date manually in your database to test this. Also, when
    visiting the sitemap, you need to first delete the cached version
    in the backend (Debug -> Settings -> Technical -> Attachments).

[1]: https://github.com/odoo/odoo/commit/4ecbacaf59576a22ff45615a5aa5c67244e4fb93

Forward-Port-Of: odoo/odoo#212055
Forward-Port-Of: odoo/odoo#211749

…ivery

**Problem:**
When a product is added to a sale order from the delivery 
the cost is not computed

**Steps to reproduce:**
- Activate the "Margins" Settings
- Open Sales/Products and create a product
- In the product Type field, choose consumable 
and set a postive cost
- Do the same for a second product
- Navigate to Sales/Order and create a new quotation
- Add your first product and Confirm
- Click on the Delivery smart button and then on the 
Detailed Operations smart button
- Click on New, add your second product and set 
a quantity of 1
- Go back to the delivery and validate it
- Go back to the sale order

**Current behavior:**
A line has been added with the product but the Cost is zero 

**Expected behavior:**
The cost should be computed

**Cause of the issue:**

Because of the elif logic here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L17-L22
the cost of products added on delivery with a standard price 
will be computed using _compute_average_price
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
We should instead add the line to "line_ids_to_pass" so 
they're computed with the super method

**Fix:**

Changing the elif logic to make sure that if a product is added in 
delivery and has a non standard cost method it's cost is computed 
here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
but if it's added in delivery and has a standard cost method,
we call the super method for this line

opw-4581531

Forward-Port-Of: odoo/odoo#208176

Steps to Reproduce:
-----------------
1) Create an Accrual
	 - Set carryover_date to other
	 - Set carryover_month to April.
	 - Set carryover_day to Last Day.
2) Add an Accrual Rule to the accrual.
3) Create a Leave Allocation
	 - Set allocation_type to Accrual.
	 - Assign the Employee.
	 - Define the Validity Period (date_from, date_to).

**Issue:**
-------------------
On accrual creation when the user selects the "last day" option for carryover_day, we are currently assigning the 31st as the day Hardcoding the 31st as the `carryover_day` can lead to errors when the `_get_carryover_date` method is triggered. For example, this causes failures in months with fewer days (e.g., February or April).

**Fix:**
-----------
evaluate the correct carryover_day based on the selected month & year when the value is set to last day, before using it to prepare the final date. This ensures that the last day of each month is accurately determined and applied.

**Traceback:**
------------
 ValueError: day is out of range for month


**OPW:** 4792938

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

Forward-Port-Of: odoo/odoo#211205

**Steps to reproduce:**
- Install Accounting and l10n_es_edi_facturae
- Switch to a Spanish company (e.g. ES Company)
- Create or edit a Spanish customer and set "Facturae" as eInvoice format
- Create an invoice:
  * Customer: [the Spanish customer]
  * Product: [any]
  * Customer Reference: [anything]
- Confirm the invoice
- Generate Facturae edi file via "Send & Print" button
- Check the generated XML

**Issue:**
When submitting the XML to FACe service, the XML is rejected with the following error:
"Element 'ReceiverContractReference': This element is not expected. Expected is one of ( FileDate, SequenceNumber, DeliveryNotesReferences, ItemDescription )."
It is caused by "ReceiverContractReference" being set after "FileReference" in the invoice line section.
Apparently, the order defined in the documentation should be respected.
"ReceiverContractReference" should be set before "ReceiverTransactionReference".

The issue has been introduced by this other fix:
https://github.com/odoo/odoo/commit/ac1af565161d70d57f51d579d0530eb7766c0c76

opw-4579987



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

Forward-Port-Of: odoo/odoo#211177

Steps to reproduce:
- Open Follow-up levels for 15 days -Check the option for “Automatic”
- Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration.
- Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic.
- There will appear a red ribbon on the right corner that says “In need of action”
- In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup”
- Run this action manually

Issue:
Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address

Note:
This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses.

Cause:
When running the cron, the recipients aren't in the options

Solution:
Add an helper to find all necessary recipients from the template if no recipient ids in the options

opw-4527398

Forward-Port-Of: odoo/enterprise#84714
Forward-Port-Of: odoo/enterprise#83944