Issue:
The grid elements on the import Lots dialog are placed in one column instead of two, which misses up the layout.

Reproduction steps:
1. install "purchase_stock"
2. create a product tracked by lots
3. make an RFQ for that product and confirm it
4. click on the generated receipt smart button
5. in "Operations" tab, click fa-list icon to open the dialog
6. in the dialog, click "Import Serials/Lots

Reason:
The bug was introduced in [239e75b1385fa023e97396baa0c8d46c50997dda](https://github.com/odoo/odoo/commit/239e75b1385fa023e97396baa0c8d46c50997dda#diff-1377579fdb76de80cd31ca67d798b752a90600ab4c82a3c8799786a130b7a46fR431-R433), where the following style was added
```css
.o_cell:first-child:last-child {
    grid-column: span 2;
}
```
which applies for the children of the first and the third grid elements; However, since the first and the third grid elements have `display: contents`, the `grid-column: span 2` of their children messes up the grid layout, and makes it 4x1 instead of 2x2.

The fix:
Remove `display: contents` on the first and third grid elements, as it seems to not be useful. Have tested on web and mobile layouts.

opw-4505725

Versions:
---------
18.0+

Issue:
------
When uploading a document using the `Upload` button, the document is always assigned to the user's main company, regardless of the selected company.

Steps to Reproduce:
-------------------
1. Create a secondary company that the current user can access.
2. Navigate to Sales / Configuration / Sales Orders / Headers/Footers.
3. Switch the user's current company to the secondary company.
4. Click the `Upload` button and select any document.
    - Notice that no document is added to the secondary company's scope.
5. Switch back to the primary company.
    - The uploaded document is available under the primary company instead of the secondary one.

Cause:
------
During the upload process, no company-specific information is provided to associate the document with the selected company.

Due to the inheritance of the `ir.attachment` model, it uses `self.env.company` as the default company value for the document[^1]. Because the upload happens via the `HttpDispatcher`, no `allowed_company_ids` context value is provided to the request. Without this context value present, `request.env.company` defaults to the main company of the current user[^2].

Fix:
----
Use the `company_id` associated with the relevant `sale.order.template` (`False` when uploading documents not linked to a template).

opw-4472602

[^1]: https://github.com/odoo/odoo/blob/d99e44f22634ac589a940d85fab84ca2b2e85332/odoo/addons/base/models/ir_attachment.py#L408-L409
[^2]: https://github.com/odoo/odoo/blob/d99e44f22634ac589a940d85fab84ca2b2e85332/odoo/api.py#L680-L681

[FIX] l10n{latam_invoice_document,hu_edi}: layout header & footer issues

Bubble and wave layout footer content of l10n_ar edi invoice qr code
was a little bit cut off in preview. In addition when you had both,
`l10n_hu_edi` and `l10n_latam_invoice_document` installed, you would
have a double header/footer. And the header of bubble/wave layout
does not have the bubble/wave. Last, there is some space between the 
document and the "shadow" of the document in portal preview which 
looks weird when the selected layout is bubble or wave which normally 
goes all the way until the margins.

How to reproduce:
- install l10n_latam_invoice_document
- move to (AR) Responsable Inscripto" company
- Switch Document Layout to "Bubble" format
- Create an invoice with B2B customer
- make sure the Document Type is set to "(1) INVOICES A".
- Make sure the Journal is "Electronic Invoice"
- Validate the invoice
- Click on Preview button

What's wrong here:
1. At the bottom of the invoice, the CAE and CAE Due Date fields are
   cropped
2. Also if you installed l10n_hu_edi, you will have a double
   header/footer
3. The header does not have the bubble
4. The bubble doesn't go all way until the margins in portal preview

Regarding the first issue, this commit fixes it by moving
the custom footer to `o_content_footer` instead of it replacing the
whole footer. This was done for all `l10n_hu_edi` layouts as well as
`l10n_latam_invoice_document` layouts for consistency

For the second double header/footer issue, added a check before
overriding:
- company._name == 'res.company' to avoid breaking Configure Document
  Layout wizard (there the `comptany` is of model `base.document.layout`
- only override if fiscal country corresponds to that of the localisation

And for the last issue with header not rendering as expected, this
commit uses another xpath for header overriding as in
[#192650](https://github.com/odoo/odoo/pull/192650)

opw-4411237

Versions
--------
- 18.0+

Steps
-----
1. Have a partner using a different language;
2. set up an invoice or quotation for the partner;
3. add a line with a product;
4. click on the line to add a description below the product name;
5. preview the document.

Issue
-----
The product name is shown twice: once untranslated and once translated.

Cause
-----
Commit cf7290cbd8cc1 auto-prefixes the product's name to the line's label, and attempts to remove it for display. This only works when user & partner use the same language. As the product name is added to the label in the partner lang, it will no longer match the product name in user lang, leading to duplicate lines getting displayed for the partner, with the first using an inappropriate language.

Solution
--------
The description is already auto-filled using the product's name, translated to the partner's language. By not prefixing the product's name a second time, users don't have to empty the description first before editing it, and product names are no longer displayed in the wrong language.

opw-4496918

The recurring subscription amount displayed in the sidebar of the subscription order portal view is incorrect. For companies using multiple currencies, the displayed amount is based on the database's base currency but is shown with the expected currency symbol. This discrepancy can cause issues when extending a subscription, as clients may not be charged the correct amount.

For example, a product priced at €10 EUR should require the customer to pay ¥75.15 CNY. However, due to the previous use of the total_amount field, the customer only needed to pay ¥10 CNY to extend their subscription. The total_amount_currency field resolves this issue by correctly converting and displaying the amount in the expected currency.

Before Fix:
![Screenshot from 2025-02-10 12-04-59](https://github.com/user-attachments/assets/66395583-fb8a-44c9-8600-6aeb4c7a2ade)
After Fix:
![Screenshot from 2025-02-10 12-05-35](https://github.com/user-attachments/assets/d7ab2b4d-c279-4a9e-ad8d-fc20c660bf9f)


Task-4484696

Users can access different metrics to evaluate their financial
performance, both from the accounting app and from the accounting
dashboard in the dashboard app.
However, the values to compute the metrics are retrieved independently
and this is causing an issue with the computation of Net profit margin

Steps to reproduce:
- Add an invoice (to have income) and a bill (to have expenses)
- Check Net profit margin in Dashboards > Finance > Accounting
- Check margin also in Accounting > Reporting > Statement Reports > Executive Summary

Issue:
Net Profit margin in executive summary and accounting dashboard differs.

Reason:
Net Profit margin is defined as NEP/INC
- NEP is:
  - In dashboard OPINC + OIN - COS - EXP - DEC
  (All accounts type income and other incomes minus expenses)
  - In executive summary REV + OIN - COS - EXP - OEXP
  (Same as above)
- INC is:
  - In dashboard OPINC + OIN
    (All accounts type income and other incomes)
  - In executive summary REV - COS - EXP
    (All accounts income type - Account type cost - all expenses)

Solution:
Correct Net profit margin computation in execute summary to use the
income and not the operating income, as in the latter the expenses have
been already deducted

opw-4450678

## Issue:
When we upload a pdf document to a folder and remove access to that folder, if we attempt to split the document it shows an unralted error.

## Steps to reproduce:
- install documents_project
- Open documents app
- Select "Projects" folder
- Upload a pdf document
- Edits "Projects" folder sharing settins to remove Mitchell Admin and restrict Internal users to None
- Select the pdf document and click on "Split" button
- Try to split the document
- Not possible due to folder access error but the error message is not related to the issue

## Solution:
- In the `PdfManager` component, we noticed that inside the `_sendChanges` method, we don't verify whether the response from the `pdf_split` controller is JSON before calling `.json()`. As a result, when we attempt splitting, an access error is raised in the controller, and Werkzeug returns an HTML error response by default. This leads to an error when `.json()` is called, which is eventually caught in `_applyChanges` and displayed in the notification instead of the intended access error.
- this fix handles the error response from the `pdf_split` controller better by checking if the reponse is ok before calling `.json()`, and handling the error response accordingly.

OPW-4453150

This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure.

- Install the `eCommerce` module without demo data and with Indian localization.
- Install `Razorpay payment provider` and activate `developer mode`.
- Add `Key ID` and `Key Secret` in Razorpay payment `provider`.
- Set up webhook in Razorpay dashboard with a random `Webhook Secret`.
- Go to the `website`, add the product to the cart, and proceed to payment using
 `UPI`.`

`Error: 'bool' object has no attribute 'encode'`

This issue occurs because the Webhook Secret is missing, returning False and causing payment verification to fail.

This commit solves the error by handling missing `Webhook Secret` values by
logging a warning and skipping the signature check instead of returning a False.

Sentry: 6208134651

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

Forward-Port-Of: odoo/odoo#197136
Forward-Port-Of: odoo/odoo#196125

steps to reproduce:
- Install the module approvals_purchase
- As admin user
- go to approvals
- create a new approval for RFQ request
- attribute the approval to an user without any access rights
- put yourself as the approver
- submit and validate the approval
- click on the button Create RFQ's
- create the RFQ
- logout and connect as the user without access rights
- try to access your approval -> Access Error

related infos:
first appeared with: https://github.com/odoo/enterprise/commit/4220723e0779287e5a8e301553e1a870cd3c4ca5 in task: 2040710

Reason:
No group where set on the button 'Purchase Orders' which is used to access the RFQ from the approval
this button needs a protected field to be able to
be displaed properly in addition to that no default value was set if the user has no rights to read the 'purchase.order.line' model.

Expected behavior:
The button should not be displayed if the user has no access rights to the RFQ and thus grand access
to the approval of the user

FIX
add a default value if the user has no read rights on the model 'purchase.order.line'  ultimatly making everything related to it in the form view invisible
Also add a group to it in the view to permit to remove the default value in master

task-3561514

Forward-Port-Of: odoo/enterprise#79098
Forward-Port-Of: odoo/enterprise#78275