**Steps to reproduce :**

1) Install Accounting and enable Analytic Accounting from the configuration. 
2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 
3) Add a line with domain set to miscellaneous, applicability as mandatory and a prefix
4) Create an analytic account using the smart button on the plan. 
5) Create an asset record in one company in a multi-company setup. 
6) Switch to another company and try to access the asset created in the first company.

**Issue:**
A traceback occurs
```
AttributeError: 'bool' object has no attribute 'startswith'
```

**Cause:**

- When switching companies, all the chart of accounts records code for the previous company, will set as False.
- 
  When accessing an asset record expects a account code to call .startswith(), 
  but it fails when code is False. This leads to the above traceback.
https://github.com/odoo/odoo/blob/5a321b2327e36f3250b33c669bdb8bb344ab4cbd/addons/account/models/account_analytic_plan.py#L64-L67

**Solution:**
- Add a check to ensure that the account’s code exists before attempting to call .startswith().
  This makes the code more robust across multi-company environments.

opw-4745633

Forward-Port-Of: odoo/odoo#210741

**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:**

1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR`

**Result:**

```
2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml
2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv
2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml
2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res_lang"\n
    SET "url_code" = "__tmp"."url_code"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4\n
    FROM (VALUES (68, \'es\', \'2025-01-03T11:41:26.517428\'::timestamp, 1)) AS "__tmp"("id", "url_code", "write_date", "write_uid")\n
    WHERE "res_lang"."id" = "__tmp"."id"\n'
ERROR: duplicate key value violates unique constraint "res_lang_url_code_uniq"
DETAIL:  Key (url_code)=(es) already exists.
```

**Explanation:**

When initializing a new database with a specific language, the language is activated on `install_lang`, and since it's the only active language of the "es_*" family, its url_code is set to the short version. [^1]

By the time the url_code switch in `res_lang_data.xml` is executed, the `base.lang_es` language is no longer the one with "es" as url_code. It's actually the recently activated es_AR language.

**Solution:**

We must perform the `url_code` switch before calling `install_lang`

[^1]: https://github.com/odoo/odoo/blob/c042e1ba/odoo/addons/base/models/res_lang.py#L339-L356


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

Forward-Port-Of: odoo/odoo#192344

[FIX] account: customer's default invoice template as only attachment

Currently, when the user define an invoice template other than the
standard 'account.account_invoices', both the standard report and the
one defined by the user are attached to the mail when he hits the Send &
Print. We want the template chosen by the user to be the one sent &
printed.

The fix is to remove the default accounting action report from the
dynamic attachments : before, we were just removing the default action
report used for the current move. But e.g. if the partner had a default
report set in the field invoice_template_pdf_report_id, the default
report for the move was this one, and so we weren't removing the
accounting default one. This was causing the duplicate placeholder
because the default accounting report placeholder is already processed
in another method.

Also, we remove the configuration that sets the
'account.account_invoices' report as a default dynamic attachment.

Task-4681142
Runbot : https://runbot.odoo.com/runbot/bundle/18-0-invoice-report-per-partner-roto-361127

Forward-Port-Of: odoo/odoo#205121

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

When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. 

However, the current implementation does not properly handle this, with the default crone job running daily sending  email reminders up to one day late.


### Current behavior before PR:

Although the current implementation ensures the crone is not triggered for alarms of external-calendars-synced events, the default crone job that is running daily is going all over the events with reminders need to be sent and send them up to one day late.  

### Desired behavior after PR is merged:
When the crone goes to trigger the _send_reminder method, it will check first if the events are synced or not, and if synced then no reminders will be sent from odoo's side.




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


task-id: 4316693

Forward-Port-Of: odoo/odoo#211790
Forward-Port-Of: odoo/odoo#192876

Installing PoS will change some values on existing operations types.

To reproduce the issue
1. Install stock
2. Operations Types, edit Delivery:
   - Change the barcode
3. Install point_of_sale

Error: the barcode of Delivery is reset

When installing PoS, it will execute a generic method that creates
and updates all operation types:
https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/point_of_sale/data/point_of_sale_data.xml#L4
https://github.com/odoo/odoo/blob/14e9a698e333c3d6d2f7830353c34311de9ecb2c/addons/point_of_sale/models/stock_warehouse.py#L45-L50
https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L350-L356
Thanks to this, the PoS operation type will be created. However, as
said in its docstring, the method will also update the existing
operation types. For instance, for Delivery:
https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L1003-L1006
Its barcode and default source location will be reset. The update
will also reset the sequence prefix.

As said by the method name in PoS (`_create_missing_pos_picking_types`),
the idea here is just to create missing PoS types.

Similar issue with repair: the operations types of the user-created
wh will be reset.

OPW-4668505

Forward-Port-Of: odoo/odoo#210308

[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

**Current behavior:**
COGS dashboard items in a project's profitability report do not open any details when clicked on.

**Expected behavior:**
This should open a detailed view for an invoice linked via the analytic account on the project.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report and click on the `Cost of Goods Sold` dashboard item

**Cause of the issue:**
There is no action set up to return for this section, as it was just added in: 0fbc592

**Fix:**
Add an action to return the account move line records with COGS display type for the invoice record in question (in the request's `res_id`).

opw-4813885

Forward-Port-Of: odoo/odoo#212547

**ORIGINAL Issue:**
When an email with an attachment was sent to a project alias (configured
to create tasks and documents in a specific project), and the target
project's Documents folder was explicitly owned by a company (`Company2`)
distinct from the current system company (`Company1`), the alias
creation process for the resulting documents would fail.
The error message indicated a domain mismatch: "We could not create
alias Inactive Alias because domain company1.com belongs to company
YourCompany while the owner document belongs to company Company2."

**Changes in 18.1 FW**
This commit adapts the existing mail alias company test to the `documents_hr_recruitment`
module context for saas-18.1. Previously, the test targeted `documents_project`,
but changes in saas-18.1 indicate that sending an email to a project alias
no longer creates documents via the `document.mixin` in the same way.

The core bug remains: ensuring that when a document is created via an incoming
email alias, and it targets a folder explicitly owned by a specific company
(in a multi-company setup), the created document and its associated alias
correctly inherit that folder's company, preventing alias domain mismatch errors.

**Proposed Solution and Justification:**
The chosen solution centralizes the `company_id` assignment for new
documents within the `_get_document_vals` method of the
`documents.mixin.DocumentMixin` abstract model. This method is the
primary entry point for determining default values when any model
inheriting `DocumentMixin` creates a linked `documents.document` record.

The fix ensures that when `document_vals` are prepared, the `company_id`
of the new document is explicitly pulled from the `company_id` of its
designated `folder` (retrieved via `_get_document_folder()`).

**Steps to reproduce (multi-company in 18.1 with documents_hr_recruitment):**
1.  **Install Modules:** `hr_recruitment` and `documents` are installed.
2.  **Create Company-Owned Folder:** A Documents folder (`hr-company2`) is created and explicitly owned by Company 2.
3.  **Configure HR Recruitment Workspace:** In Documents settings, the recruitment workspace is configured to use the `hr-company2` folder. This is done by setting `documents_recruitment_settings` and `recruitment_folder_id` on `res.company` for Company B.
4.  **Create Job Posting:** A new job posting is created in `hr_recruitment` (owned by Company 2) with an email alias.
5.  **Simulate Incoming Email:** An email with an attachment is sent to this job posting's alias.
6. **Error**: mail alias during document creation fails because of miss-matched companies

opw-4727873

Forward-Port-Of: odoo/enterprise#86389

Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period.

**Steps to Reproduce**
1) Install **l10n_id_hr_payroll module**.
2) Create a new **Pay-Slip**.
3) Remove **Date** from **Period**

**Error:**
`AttributeError: 'bool' object has no attribute 'month'`

**Root Cause:**
The `_compute_l10n_id_include_pkp_ptkp` method at [1] assumes that `date_to` and `contract_id.date_end` are always set and valid. If either of them is missing (False), accessing `.month` or `.year` causes an error.

[1] - https://github.com/odoo/enterprise/blob/34aa0ffb82c1bd7c90b4cb161ea515f2cad8e65f/l10n_id_hr_payroll/models/hr_payslip.py#L87

**Solution:**
This commit prevents the computation from failing when `slip.date_to` and `slip.contract_id.date_end` fields are unset by adding a conditional check to ensure that both fields are valid date objects before accessing their `.month` and `.year` attributes.

sentry-6608982173

Forward-Port-Of: odoo/enterprise#85701