Prior to this commit, the `FormStatusIndicator` buttons were not properly aligned with the content of the breadcrumb in the control panel.

This commit adjusts the alignment of `FormStatusIndicator` correctly according to the content of the breadcrumb.

Also, to align the cog menu perfectly with the "save" and "cancel" buttons, we've removed the border around the latter two.

task-3874495

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-05-13 à 16 04 53](https://github.com/odoo/odoo/assets/80679690/8699c6c2-be00-4ed9-b193-01fad2445de1) | ![Capture d’écran 2024-05-13 à 16 04 45](https://github.com/odoo/odoo/assets/80679690/9dc09cb2-bdf8-401c-8f48-978eb022f7ef) |
|  ![Capture d’écran 2024-05-13 à 16 07 33](https://github.com/odoo/odoo/assets/80679690/97f02e22-06b4-42c1-9e02-b0bb57c5c972) | ![Capture d’écran 2024-05-13 à 16 07 20](https://github.com/odoo/odoo/assets/80679690/f031a83a-ae60-4459-bbb8-80f1c2ad6fab) |





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

Forward-Port-Of: odoo/odoo#186463

Steps to reproduce:
- Sales app > Configuration > Settings > Enable 'Quotation Templates'
- Default template > Search more > New
- Set 'Confirmation Mail' to 'Sales: Order Confirmation'
- Project app > New > Enable 'Billable' in the project's settings
- New Task > Set any Customer
- Sales Order Item > Search More > New > Add product then save
- Click 'Sales Order' button

Coupled with https://github.com/odoo/enterprise/pull/73492

You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation.

The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled.

opw-4190402

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

Forward-Port-Of: odoo/odoo#187807
Forward-Port-Of: odoo/odoo#183586

The website module overrides `ir.http:_get_default_lang`, which is called by `http_routing`'s override of `ir.http:_match`.
In this override, it calls `website:_get_cached('default_lang_id')` which calls `website:_get_cached_values`.

However, `ir.http:_match` is called at a time when the environment hasn't been completely initialized (it will be properly initialized when `ir.http:_authenticate` is called), and its context language hasn't been checked against activated languages yet.

This means that `website:_get_cached_values` cannot rely on this language. The first of the two bugs fixed by this commit happens when website has translatable fields. When reading data from the website, the ORM does a prefetch and tries to load this other field, but fails because the language of the context is invalid. The fix is to prefetch manually the four fields that are not translatable and that we want to cache.

The second bug happens specifically on the logout page, which is set as `auth='none'` by the web module. The website module already overrides the `/web/login` route to set it as `auth='public'` in order to be able to read the website. We need to do the same with the /web/session/logout route, so that the page renders properly.

This commit targets saas-17.2 as the first branch because it is fixing two bugs that were introduced as follows, as determined by a git bisect.
- in a3a3650 from #112000 (saas-17.1), the call to /web/session/logout fails with a 500 status (IndexError) because rule.endpoint.routing has no 'no_db' key, in '_serve_ir_http'.
- in 584a172 from #112000 too (saas-17.1), that code is removed, and the error is now a 403 status because it is not possible to read website records without a user. This error is fixed by adding user='public' to the logout route.
- since d01302b from #151502 (saas-17.2), the test added in this commit could reproduce the error in _get_cached_values by accessing the logout route.

As the saas-17.1 is already EOL, we target saas-17.2 and forward-port it to master.

[OPW-3721341](https://www.odoo.com/odoo/project.task/3721341)
[OPW-3911437](https://www.odoo.com/odoo/project.task/3911437)

Forward-Port-Of: odoo/odoo#187313

**Steps to reproduce:**
- Install Accounting and Point of Sale
- Open a "Point of Sale" session
- Create a POS order and pay it by bank
- Create another POS order and pay it by Customer Account
- Close POS session
- Go to Accounting
- Open Bank journal
- Create a statement line and reconcile it with the POS payment
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Check the amount of the POS orders in the following journals:
  * [101300] Account Receivable (PoS)
  * [121000] Account Receivable
  * [400000] Product Sales
- Check "Cash Basis Method" in the options
- Check again the amount of the POS orders in the same journals

**Issue 1:**
The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet.

**Extra steps:**
- Create another statement line and reconcile it with the POS customer account payment
- Check again the amount of the POS orders in the same journals

**Issue 2:**
The amount of the POS orders is double the original amount.

**Issue 3:**
If a partial payment is made for one line, the report has incorrect values.

**Cause:**
To retrieve the cash basis lines, a complex SQL query is executed.

Let's take the following entries:

- Invoice:

| account | debit | credit |
| ----------- | -------- | -------- |
| Account Receivable 1 |  100  |   0 |
| Account Receivable 2 |  200  |   0 |
| Product Sales |   0   |  300 |

- Payments:

 | account | debit | credit |
 | ---------------- | ------------ | ----------- |
 | Bank | 50 |    0 |
 | Account Receivable 1 |   0   |   50 |

 |       account        | debit | credit |
 | ------------ | ---------------- | ----------- |
 | Bank                 |  200  |   0 |
 | Account Receivable 2 |   0   |  200|

A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed:

| move_id |             matched_percentage|
| ------------------|---------------------------------|
|    1    | 0.5 (50% paid for Account Receivable 1)|
|    1    | 1.0 (100% paid for Account Receivable 2)|

This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts.

Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here.
As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to.
As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't.
In this example, they are taken into account twice because the 2 entries have the same move_id.

Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time.
For example, these 2 lines are computed from the tempory table for "Product Sales":

* Product Sales = 300 * 0.5 = 150 (for Account Receivable 1)
* Product Sales = 300 * 1.0 = 300 (for Account Receivable 2)

The amount for "Product Sales" sums to 450, which is not correct.
It should be 250.

**Solution for issues 1 and 2:**
Get account_id and join account_move_line table on it.
An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts.

**Solution for issue 3:**
Compute a ratio for "Product Sales" for each receivable account.
Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2"
So its ratio should be:

* 100 / 300 = 0.33 (for Account Receivable 1)
* 100 / 300 = 0.66 (for Account Receivable 2)

By applying this ratio, the correct amounts are computed for "Product Sales":

* Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1)
* Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2)

opw-4224136

Forward-Port-Of: odoo/enterprise#74237
Forward-Port-Of: odoo/enterprise#73593

### Steps to reproduce:
	- Create a new project and set it to be billable.
	- Set an analytic account on it
	- On the analytic account, set a plan that is not the default plan
	- Create a sale order for a subscription product with this analytic account and confirm it.
	- Create an invoice and confirm it.
	- Go to the project and click on Status Updates
	- Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product
	- If we change the plan on the analytic account, we will be able to see the invoiced amount on the profitability report

### Current behavior before PR:
When setting analytic account with different analytic plan than the default one the analytic account value will be stored in x_plan{plan_id}_id field when creating the analytic account line record. https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/account/models/account_move_line.py#L3092

https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L106:L122

So when fetching the profitability data for a project we are just checking the account_id field.
https://github.com/odoo/enterprise/blob/17.0/project_sale_subscription/models/project.py#L111:L115

### Desired behavior after PR is merged:
We are now using the same method of _column_name() to know which field should we use in the domain whether it is 'account_id' or 'x_plan{plan_id}_id'

opw-4137931

Forward-Port-Of: odoo/enterprise#70508

Steps to reproduce:
- Sales app > Configuration > Settings > Enable 'Quotation Templates'
- Default template > Search more > New
- Set 'Confirmation Mail' to 'Sales: Order Confirmation'
- Project app > New > Enable 'Billable' in the project's settings
- New Task > Set any Customer
- Sales Order Item > Search More > New > Add product then save
- Click 'Sales Order' button

Coupled with https://github.com/odoo/odoo/pull/183586

You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation.

The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled.

opw-4190402

Forward-Port-Of: odoo/enterprise#74133
Forward-Port-Of: odoo/enterprise#73492

### Steps to reproduce the issue:

1. Activate Mexican Localization
2. With a Mexican Company, create an Invoice and add a Product with a valid UNSPSC code
3. On the Invoice Line, set Price to 1030.17 and add a 3% Discount
4. Confirm then Send & Print (with CFDI checked)
5. In the generated XML, the following values are off:
    - In node "Comprobante, SubTotal="1030.16" Descuento="30.90"
    - In node "Concepto", ValorUnitario="1030.16" Importe="1030.16" Descuento="30.90"
    - Expected are 1030.17 and 30.91

### Explanation:

During the calculation of the values for the CFDI, `gross_price_subtotal_before_discount` is calculated using `price_subtotal` in every case where `discount` is not 100%. This is due to other values affecting `price_subtotal` (e.g.: taxes with `price_include=True`), in which case calculating a value related to `price_subtotal` with `price_unit` would give the wrong result.
This calculation method causes rounding issues such as above because `price_subtotal` is rounded before calculating `gross_price_subtotal_before_discount`.

### Fix reasoning:

We need to account for any value that could affect `price_subtotal` and make it different from `price_unit * quantity` except for `discount`, which will be included when comparing both values.
The case `discount == 100.0` is covered by this new condition as well, since `discount_factor` would equal to 0 and `price_subtotal` too.

opw-4183556

Forward-Port-Of: odoo/enterprise#72593