steps to reproduce:
------------------------
1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in)
2. Enable the "Anglo-Saxon Accounting" option.
3. Migrate to 18.0 version.

Issue:
-------
Commit c2d0251 , sets a default value when changing the CoA. However,
during migration, when the `_pre_load_data` function runs, it overrides the 
customer's selection even if the CoA is not changed and assigns the default
value to the `anglo_saxon_accounting` field, ignoring the customer's preference.

**Original DB:**
```psql
bona_2515224=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  6 | Handful of Health Pvt Ltd - TN | t
  4 | Handful of Health Pvt Ltd - KA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  2 | Handful of Health Pvt Ltd - MH | t
  7 | Handful of Health Pvt Ltd - GA | t
  5 | Handful of Health Pvt Ltd - RJ | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```
**Without fix:**
```psql
bona_2515224_upg=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  1 | Handful of Health Pvt Ltd - DL | f
  2 | Handful of Health Pvt Ltd - MH | f
  3 | Handful of Health Pvt Ltd - UP | f
  4 | Handful of Health Pvt Ltd - KA | f
  5 | Handful of Health Pvt Ltd - RJ | f
  6 | Handful of Health Pvt Ltd - TN | f
  7 | Handful of Health Pvt Ltd - GA | f
  8 | Handful of Health Pvt Ltd - GJ | f
(8 rows)
```
**With fix:**
```psql
bona_2515224_18.0=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  7 | Handful of Health Pvt Ltd - GA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  4 | Handful of Health Pvt Ltd - KA | t
  2 | Handful of Health Pvt Ltd - MH | t
  5 | Handful of Health Pvt Ltd - RJ | t
  6 | Handful of Health Pvt Ltd - TN | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```

opw-4542300


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

Forward-Port-Of: odoo/odoo#198011

Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line.

Step to produce:

- Install the ```hr_expense``` module.
- Create an expense, add a category, and click on the `Split Expense` button.
- Delete all expenses from the split expense line, and press the data-hotkey `ALT + Q` to click on the `Split Expense` button to split expenses.

```IndexError: tuple index out of range```

This occurs because the system attempts to access the first expense from the split expense line [1], but expenses are not available.

Link [1]: https://github.com/odoo/odoo/blob/280b762e7cd1b3d9a578bbae60cbb9b137ee5ce5/addons/hr_expense/wizard/hr_expense_split_wizard.py#L36

To resolve this issue, Disable a 'Split Expense' button after simply adding a  `disabled` attribute on it.

Sentry-6015854429

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

Forward-Port-Of: odoo/odoo#194564
Forward-Port-Of: odoo/odoo#190323

Issue addressed by this commit:
An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave.

How to reproduce the issue:

Install both hr_holidays and auth_signup modules.
Attempt to execute the _get_on_leave_ids method to identify users on leave.
Behaviour before this commit:

An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables.
Expected behaviour:

The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors.
Solution:

The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error.
opw-3770758

Forward-Port-Of: odoo/odoo#179305
Forward-Port-Of: odoo/odoo#156663

This commit adds 2 major module for handling SIE4 files within Odoo.

Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing and exporting accounting data.

In addition to the new features below, this commit also renames the current odoo implementation of SIE5 from just "SIE" to "SIE 5" to avoid confusion between the two.

This first implementation does not at all consider the effects of the `#OBJEKT` and `#DIM` (or other similar dimension) items.

---

### SIE4 Import - `l10n_se_sie4_import`

Odoo can now import accounting data from SIE of type 4 and below (thanks to backward-compatibility of SIE format).

SIE4 files are designed as a text file with label on each line and its contents. One item can be referred by another item down the file, so we need a variable (`data_map`) to save the required information for future use, in-between the reading process.

From the SIE4 file, we can then import the following data: company, chart of accounts, fiscal year, and move informations.

An option will be provided when creating the wizard to allow user to choose whether they'd like to import opening balance move, and/or update any duplicate accounts already found in their company with the one in the file.

---

### SIE4 Export - `l10n_se_sie4_export`

Odoo's implementation of exporting SIE4 files are placed in the General Ledger view's export buttons, similar to other import implementation like SAF-T and Libros.

To be able to export SIE4 file, the date periods in the selected options must be of type fiscal year, and exporting multiple companies at once is forbidden.

---

[SIE 4 documentation](https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf)

task-id: 3735808

Forward-Port-Of: odoo/enterprise#66263

Module : account_reports

Issue reproduction : 
- Go to Accounting / Configuration / Management / Accounting reports
- Edit "Journal Report"
- Activate the filter "Account types" in the options tab
- Go on Accounting / Reporting / Audit reports / Journal Report
- traceback with a psycopg2.errors.UndefinedTable error 

Cause : 
The query generated in **_query_journal()** on account_journal_report.py doesn't use **account_account** table in the FROM clause. This table is included in the  **tables** value created from **_query_get()** but this variable can't be used as it is because it starts with the **account_move_line** table for the FROM clause. 

Solution : 
Use the **tables** variable and modify the sql query. 

Versions impacted : 
- 16.0, saas-16-1, saas-16-2, saas-16-3, saas-16-4
- 17, saas-17-1 

Note : **filter_account_type** change from a boolean field to a selection field from version 17 but the error is the same

Support ticket : 3708809

Forward-Port-Of: odoo/enterprise#62146
Forward-Port-Of: odoo/enterprise#57828

[FIX] documents: fix documents creation on documents

1. Fix reply with an attachment on message from existing document

How to reproduce:
- Go to the chatter of a document
- Add yourself as a follower
- Send a message from the chatter: you should receive an email
- Reply to this email with an attachment

You receive a delivery error message ("Address not found") and your reply doesn't appear in the chatter, nor your attachment. 
With this fix, the message with its attachment appears in the chatter and there is no delivery error message.

2. Fix sending a message with an attachment on a request

How to reproduce:
- Go to the chatter of a request
- Send a message with an attachment from its chatter

You get the error "The operation cannot be completed: This attachment is already a document." while the message with its attachment should be added in the chatter.
With this fix, the message with its attachment appears in the chatter and the request remains to be fulfilled.

3. Error while uploading a requested document through activity popover

How to reproduce:
- As user A, create a requested document for User B
- As user B, click on the activity of that request and upload a document

You get the error "The operation cannot be completed: This attachment is already a document." while the uploaded file should be linked to the request.
With this fix, the request is fulfilled, and you get no error.

We solve those problems by not creating document by default when messages with attachments are posted on a document and delegate the creation of the documents to the _message_post_after_hook method for the case of a post on a folder alias. We have chosen that default behavior as in all uses case except the alias, we expect the attachment to be added to the chatter and not as a new document.

TestMailGateway already tests that incoming mail with attachment on an alias create the related documents, and we introduce a test for each case described above in other commits.

[IMP] documents: add a test on replying with an attachment on a document post

We add a test that check that when answering a mail posted on a document with an attachment, that the attachment is added to the document and the message is posted on the document.

We also modify slightly an existing test because a parameter given to _message_post_after_hook was incorrect.

[IMP] documents: add a test on document type change when sending a message

We add a test that check that when sending a message on a URL or a request document, it is not turned into a binary document.

[IMP] documents: add a test that upload a document in the activity popover

We add a test that upload requested document through activity popover.

Task-3707821

Forward-Port-Of: odoo/enterprise#78631
Forward-Port-Of: odoo/enterprise#56779

The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock.

Notes:
We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution.

Traceback: (VALUES where removed for readability, there were 100 of them)
```
2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "account_bank_statement_line"
SET "cron_last_check" = "__tmp"."cron_last_check"::timestamp, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (...), (...), (...), (...), ) AS "__tmp"("id", "cron_last_check", "write_date", "write_uid")
WHERE "account_bank_statement_line"."id" = "__tmp"."id"'
ERROR: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"

2025-01-27 12:00:39,277 3822296 ERROR openerp odoo.addons.base.models.ir_cron: Job 'Try to reconcile automatically your statement lines' (297) server action #4952 failed
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_cron.py", line 572, in _callback
    self.env.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 833, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6707, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6784, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4881, in _write_multi
    self.env.execute_query(SQL(
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 962, in execute_query
    self.cr.execute(query)
  File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 373, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"
```

task-id: 4393854

Forward-Port-Of: odoo/enterprise#80059