Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog.

1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because we tried to sort records on a field that is unknown.

2) if it wasn't the first field of the order, e.g. `default_order="x,y"` but y wasn't in the view: the changes done in the dialog were lost, so it was no possible to edit records.

Both issues had the same root cause. After the edition, we tried to sort the relation (as the order might have changed). We do that since [1], but it wasn't the main purpose of this commit. It has been done because it looked like a quick win at the time, and we thought it was a good idea.

However, functionally speaking, sorting the records after the edition isn't wanted. If I just clicked on a record, edited it, I expect the record to remain where it was after closing the dialog. So as sorting isn't necessarily wanted, and it even produces issues in some cases, this commit reverts that "feature".

[1] https://github.com/odoo/odoo/commit/17e198153ecfd9c5c32b3b22f43e2f1b8100a1c3

Closes #197867

opw-4499150 (case (2))

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#198757

The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it.

However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV.

After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we consider the request as failed and requires the user to send a new request again, we make the user send a second request on the same invoice, where the SPV actually acknowledges all of the received invoices.

After discussing with the PO, a temporary workaround for now is to increase the timeout limit to 60 seconds (1 full minute) to reduce the likelihood of this issue happening, and log error messages on the chatter if the request (either for send/fetch/download) failed, so that the user are aware when it is timeout and be more wary not to send another request right away, in case the new timeout limit are still not enough.

Other small changes in this PR:

- Handle response code 401, (which is a JSON object, invalid access token)
- Remove the "Error when sending the document to the SPV:" template in error documents (because not all error documents are for sending, some are from fetch/download)

opw-4571713

Forward-Port-Of: odoo/odoo#198604

When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state, `invoice_received`, in a validation that triggers the update of the SAT state for the current invoice.

Steps to reproduce:
<img width="1301" alt="Screenshot 2025-02-13 at 11 23 47 PM copy" src="https://github.com/user-attachments/assets/bad64936-bae1-4846-8cde-12f6d1748d46" />
<img width="1301" alt="Screenshot 2025-02-13 at 11 24 12 PM copy" src="https://github.com/user-attachments/assets/b4a839c2-a5ab-4638-b46d-3eb9ccf1b59d" />
<img width="1307" alt="Screenshot 2025-02-13 at 11 26 30 PM copy" src="https://github.com/user-attachments/assets/14645d48-5e90-405c-8a36-3ec7b0af50ef" />
<img width="1306" alt="Screenshot 2025-02-13 at 11 26 47 PM copy" src="https://github.com/user-attachments/assets/839349bf-be83-408a-bbd4-676d84a34493" />
<img width="1305" alt="Screenshot 2025-02-13 at 11 26 57 PM copy" src="https://github.com/user-attachments/assets/1e3773de-f3ab-47b4-9548-b5633c078943" />

Actual result:
<img width="1306" alt="Screenshot 2025-02-13 at 11 27 08 PM copy" src="https://github.com/user-attachments/assets/a385847e-20cc-4410-8802-6d6b2c363633" />

Expected result:
<img width="1307" alt="Screenshot 2025-02-13 at 11 27 49 PM copy" src="https://github.com/user-attachments/assets/8974cd49-13b6-40c0-8fa2-fd1fce45faf3" />

Forward-Port-Of: odoo/enterprise#79314

Purpose
=======
In the Facebook settings, a user can ask an application (eg Social) to remove his data.

If the deletion is not implemented, it should be done manually for each user, and so we want to automate that process.

Technical
=========
The deletion process is done in that order:
1. The user go to his settings and ask Odoo to remove the data we have
2. Facebook will hit an endpoint in IAP, with a signature, and the  Facebook user id
3. IAP will reach the database, (with a shared secret to authenticate itself) and that endpoint will remove the social accounts, and also the social posts / templates if the account is selected

We do it that way, instead of having a CRON on the client database, because we are able to know if the user uninstalled social, or if he already removed the account.

If the database is not reachable from the internet, we will have it's dbuuid, and so, we will be able to take an action.

Authentication
==============
IAP needs to authenticate to the Odoo database,
so both need to share a secret.

That secret can not be the extended token,
because we don't store it on the Odoo side.

That secret is derived from the database secret, and sent when we ask the Facebook URL (in python, without a browser redirection), so the social user can not see it (otherwise, he will be able to bypass company access rules, and delete the social accounts of different company).

Setup
=====
1. Start Odoo and IAP instances
2. Start ngrok on the IAP port
3. In the Facebook settings ("Facebook Login For Business" -> Settings)
    - Add <ngrok_url>/api/social/facebook/1/callback in the Facebook settings
    - Add <ngrok_url>/api/social_facebook/1/deletion_callback in the Facebook settings
4. Add the Facebook credentials in the IAP settings
5. In the Odoo db, add the system parameter `social.social_iap_endpoint` with the ngrok url
6. In the IAP db, change the system parameter `web.base.url` with the ngrok url
7. In the IAP code, in `facebook_controller.py`, comment the dbuid check `_check_has_access`
8. Add your accounts
9. Go to `https://www.facebook.com/settings/?tab=business_tools`, and remove the app
10. Go to the "Removed" tab, then "View Details" and click on "Send Request"

Task-4350697

Forward-Port-Of: odoo/enterprise#74865

This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours. 

The way this is fixed in this PR is by delaying the timezone-stripping code until it is necessary. This allows the local timezone variables, `date_from` and `date_to`, to be used to query the associated overtime records, rather than their UTC versions. We need this behavior because the "overtime" query depends on the field `HrAttendanceOvertime.date`, which is of type `fields.Date` and is timezone-agnostic.

This bug can be replicated in any variation of the following scenario (this one assumes the payslip period covers exactly one month of work):
- Create an attendance record for employee `A` that would cause them to have `h` hours of overtime at the end of month `X`, where `X` is a number in the set `{1, 2, ..., 12}`.
- Create an attendance record for `A` on the 1st of the next month, `Y := X mod 12 + 1`, with `h'` regular hours and `0` hours of overtime.
- Generate their payslip for the month `Y`.
- See that there is an overtime line with `h` hours and a regular hours line with `h' - h` hours. 🐛

opw-4371083

Forward-Port-Of: odoo/enterprise#78880