Before this commit:
-------------------
When a user added an existing signature field to a view, Studio automatically assigned the default binary widget.
The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input.
<img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" />

Cause:
-----
Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type.
Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option.

After this commit:
------------------
The signature widget is correctly exposed as a supported widget for fields of type binary.
When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list.
<img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" />


Why this fix is needed:
----------------------
Signature fields are stored as binary, but they require the dedicated signature widget to render correctly.
By marking binary as a supported field type for the signature widget, Studio can
 properly detect and offer the widget during field configuration.
Given that this widget is very domain-specific and not intended for general binary fields, it was not added to
[web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered
after this fix the option is accessible only when the debugger mode is on, if want to show this widget 
to all the binary type fields even when the debugger mode is off the we'll have to add it to this file.

OPW : 5260188


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

Forward-Port-Of: odoo/odoo#237287

… are share

If all the user type groups have the flag `Share` as true, they will be filtered out by `get_application_groups`. While updating `user_groups_view`, the field `user_type_field_name` will never be assigned, as the condition 
`app.xml_id == 'base.module_category_user_type'` will never be fulfilled.

That means that `user_type_invisible` will be `None`, but that's not a valid value and it will break.

Steps to reproduce:
- Mark all the user type groups as Share.
- Upgrade `base`.

```
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/res_users.py", line 1801, in _update_user_groups_view
    E.group(*(xml2), invisible=user_type_invisible),
  File "src/lxml/builder.py", line 204, in lxml.builder.ElementMaker.__call__
  File "src/lxml/builder.py", line 186, in lxml.builder.ElementMaker.__init__.add_dict
KeyError: <class 'NoneType'>
```

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

Scenario:

- set the report background to demo logo (621x196 pixels)
- print a report with short content (eg. quotation without lines)

Result: the logo is cropped at the bottom

Why:

Before 18.0, the background image was stretched over all the
report, so needed to be ok esthetically if stretched.

From 18.0 with https://github.com/odoo/odoo/commit/87258f05c7398173d3df6ec39869f52031502ede, the image is
only intended to be shown one time on the first page without stretching
over the whole document.

There is two issues:

- the "background-size" value "contains" is a typo of "contain"

- if we fixed the typo we would break case where the image has a portait
  aspect ratio, the image would be zoomed to fit vertically (possibly
  over several page, which is itself an issue that the commit was
  trying to fix), but since we have the value "background-position: auto
   300px" the contain is computed over the whole element area, and we
  will have 300px cropped of the bottom of the image

Fix:

This is not simple to fix, we could have used something like:

background-size: auto calc(min(100% - 300px, 800px));

but both min and calc do not seem supported by wkhtmltopdf.

So it seems that the only way to make this work better would be:

- have a min-width, so people can know that if they can use an image of
  eg. 300px (for a min-width of 600px) of height without bottom cropped

- we could fix the background-size: contain, but then we would possibly
  bring more issue for vertical image (that will be zoomed up or down
  all of a sudden) that are not solvable because of background-position.

This fix just set the min-height to 600px.

opw-4364722

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

### [FIX] website: copy the whole document to fallback iframe

Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and
the body of the website preview are copied to the fallback iframe's
document. This did not copied the attributes on the `html` node, which
somtimes impacted the appearance.

With this commit, the whole document is copied to the fallback iframe.

Steps to reproduce:
- Activate "Mobile preview" when viewing the website
- Go to a page that is long enough for a scrollbar to appear
- Navigate to another page
- Bug: During the transition, the fallback is shown, and its scrollbar
  is wider than the one of the page that was shown just before

task-5212287

### [FIX] website: remove content of fallback iframe after load

Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback
iframe is shown behind the website preview to avoid flicker on
navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the
preview for mobile has some transparency on its scrollbar. Thus the part
of the fallback iframe behind the scrollbar when previewing mobile was
slightly visible.

This commit fixes it by removing the fallback iframe's content after the
website has loaded (and the fallback is not needed anymore).

Steps to reproduce:
- On website, activate "Mobile preview"
- Navigate to a page long enough to have a scrollbar
- Navigate to another page long enough to have a scrollbar
- Scroll a bit
- Bug: The scrollbar of the fallback is slightly visible

task-5212287

Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2 kits with different variants.

Steps to reproduce:
-------------------
* Create a product P
* For product P, create an attribute with type "No variant" and values V1 and V2
* Create a BoM Kit for product P, with 3 components C1 C2 and C3
  - C2 applies only for variant V1
  - C3 applies only for variant V2
* Create a POS order with 2 lines of product P:
  - 1 with variant V1
  - 1 with variant V2
* Validate the order and check the created picking
> Observation: Only C1 and C2 are in the picking, C3 is missing

Why the fix:
------------
When creating the picking, the code was grouping the order lines by product only, and not by product variant. Therefore, the 2 lines would be grouped together, and only one of the variant-specific components would be taken into account.

opw-5051289

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#93034

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)