**Steps:**
- open documents in list view in dark mode
- select and deselect a record

**Observation:**
- the selected record's background becomes white and text was already white
- hence nothing can be seen clearly

**Cause:**
- Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode

https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36

[1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7

**Fix:**
- instead of hardcoding color, we use already available variable, which adjust the color, according to theme.

**Before:**
<img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" />

<img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" />


<br><br>
**After:**
<img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" />

<img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" />


opw-5261669

Forward-Port-Of: odoo/enterprise#100114

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

Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.

Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
     contenteditable="true">
  text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.

Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.

Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.

opw-5184309

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

Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

Forward-Port-Of: odoo/odoo#237411
Forward-Port-Of: odoo/odoo#236454

- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF.
This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default.
As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download —
since the invoices weren’t sent and no fallback was allowed.

**Steps to reproduce:**
**1:** Go to Invoices
**2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page

**What this patch does:**
- It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful.

**Possible improvements to consider:**
**1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore.

**2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once.

**3:** Instead of showing a blank page for non-sent invoices, show a user-friendly
 error message. (I noticed this was in the original commit
odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was
 introduced but was later removed — not sure why.)

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

Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI:
**For invoices that have been rejected by DGI:**
 - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt.
 - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. 
 
**Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** 
- Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status.
- Make 'Update DGI status' button always visible to be able to adjust invoices states.

**== Context of the Problem ==**

Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued.
For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button.



**== Automatic Notification Logic ==**
With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows:

_Scenario 1: Invoice with Internal Followers_

- If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions:
- It will post a message in the invoice chatter.
- It will tag (@) all internal followers to notify them directly.


_Scenario 2: Invoice without Internal Followers_

- If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed:
- It will post a message in the invoice chat.
- It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager).


Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form)
Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799)

Forward-Port-Of: odoo/enterprise#98210
Forward-Port-Of: odoo/enterprise#94502

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

Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.

Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
     contenteditable="true">
  text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.

Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.

Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.

opw-5184309

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

Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#99831
Forward-Port-Of: odoo/enterprise#98983

When paying online with the PoS if for some reason the client closes the
web page before receiving the payment confirmation, the PoS would not be
notified that the payment was successful.

Steps to reproduce:
-------------------
* Setup any online payment method in the PoS.
* Open the PoS and create an order.
* Proceed to payment and choose the online payment method.
* Scan the QR code and close the page before receiving the payment
  confirmation.
> Observation: The PoS will need to wait atleast 10 minutes to receive
  the payment notification.

Why the fix:
------------
When using the online payment method, the user that scans the QR code
will open a web page to complete the payment. This webpage is also
responsible to poll the status of the payment. When polling the status
of the payment, if the payment is successful, the server will send a
notification to the PoS to update the order status. If the user closes
the web page before the payment is confirmed, the PoS will not receive
the notification. We will need to wait for the payment transaction
`_cron_post_process` to be executed, which happens every 10 minutes.

So the solution is to trigger the cron when the payment is set as done
to ensure that the PoS receives the payment notification as soon as
possible.

opw-4925349

The budget section of the project dashboard now displays budget types:

```
╔═══════════════════════╦══════════╦════════╦════════════╗
║                       ║ Forecast ║ Actual ║ Difference ║
╠═══════════════════════╩══════════╩════════╩════════════╣
║ Expense                                                ║
╠═══════════════════════╦══════════╦════════╦════════════╣
║ Office Setup          ║ $3,500   ║ $1,200 ║ $2,300     ║
╠═══════════════════════╬══════════╬════════╬════════════╣
║         Total Expense ║ $3,500   ║ $1,200 ║ $2,300     ║
╠═══════════════════════╩══════════╩════════╩════════════╣
║ Revenue                                                ║
╠═══════════════════════╦══════════╦════════╦════════════╣
║ Client Project Alpha  ║ $1,000   ║ $6,800 ║ $700       ║
╠═══════════════════════╬══════════╬════════╬════════════╣
║ Website Redesign      ║ $2,300   ║ $2,000 ║ $300       ║
╠═══════════════════════╬══════════╬════════╬════════════╣
║         Total Revenue ║ $2,400   ║ $8,800 ║ $1,000     ║
╠═══════════════════════╩══════════╩════════╩════════════╣
║ Both                                                   ║
╠═══════════════════════╦══════════╦════════╦════════════╣
║ Subscription Services ║ $2,200   ║ $1,900 ║ $300       ║
╠═══════════════════════╬══════════╬════════╬════════════╣
║            Total Both ║ $2,200   ║ $1,900 ║ $300       ║
╚═══════════════════════╩══════════╩════════╩════════════╝
```
The difference amount is also highlighted with an appropriate color based on its
budget type, improving clarity and usability.

task-4497632

*:appointment_account_payment

NEED
====

Before this change, users could not make a manual link between meetings
and a sale order, as is the case when booking a paid appointment. This means
that when in the back-end, the user can create a meeting for a paid appointment
but cannot link it to a SO(L).

SOLUTION
========

In order to centralize the management of appointments, in terms of quick
overview and creation, we want the user to still be able to create new
appointments from the gantt view, even in this use case. Therefore, we do
not implement a product configurator, like we did in Event for instance.

Instead, we simply give a visual feedback, being a top left triangle on
the gantt pill, when the meeting is linked to a paid appointment, but not
to any SO(L), meaning a payment may be due.

Then, on the form view of the calendar event, we add a button to create
a SO (when no SOL is linked, at least one partner beside the organizer
is set, and other conditions are met, see show_so_creation_button)

This button opens a new wizard, that allows some limited customization
before creating the SO: the user can choose between attendees (beside
the organizer's) and also toggle a confirmation of the SO on creation.
The appointment and the total reserved capacity are also reminded there.
Finally, the user can either create the SO or create and open it, in
order to inspect (and eventually modify) the created record.


Task-5012248

Not having a company on the quality alert team is making incoming emails 
sent to the alias having a 'company_id' false, defined by the default values.

If manually created, a quality alert should have a company.

In order to avoid company_id issue, enforcing it to the team will add it 
to the default values of the alias and to the quality alert created by emails.

To reproduce:
1. install `quality`
2. add a second company
3. Create 2 mail.lias.domains:
company1.com
company2.com
And assign them to distinct company records by selecting them on the companies menu.
4. On the configuration of the quality team, add a localpart to the alias (like
alias_c1, to make the address alias_c1@company1.com).
Don't set a company (this field is not required anyway)
5. Send an email using the send-mail script:
odoo/addons/mail/static/scripts/odoo-mailgate.py
And using the `MAIL_TEMPLATE` defined in 
odoo/addons/test_mail/data/test_mail_data.py
after setting the to the alias of the company: alias_c1@company1.com
And giving a value to the following headers:
- Return-path,
- From,
And deleting the following headers:
- Cc,
- Message-id
6. Error:
``` 
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.

Model: Quality Alert (quality.alert)
Field: Company (company_id)
``` 
As the company is not mandatory on the step 4.



completing 159309e7c17e0ef8274d89d90bcab1b97b40023b

opw-4866977

Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.

Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
     contenteditable="true">
  text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.

Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.

Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.

opw-5184309

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

Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910

**Steps to Reproduce:**
1. Install the "**Belgium - Accounting**" (`l10n_be`) module with demo data.
2. Switch to the company - **BE Company CoA**.
3. Remove the "**Tax Payable Account**" from all the tax groups.
4. In setting, under _EU Intra-community Distance Selling_ section, click on "**OSS Tax mapping**".

**Error:**
`ValueError - External ID not found in the system: account.1_oss_tax_group_20_0_SK`

**Note:** If only the "**Tax Receivable Account**" is removed from all tax groups. The following error occurs;
`TypeError: expected string or bytes-like object`

**Cause:**
At [1], the system searches for a tax group with a defined `tax_payable_account_id`.
Also, at [2], the `oss_tax_group_local_xml_id` is created only when the tax group (tg) exists. However, when no tax group is found, the code tries to fetch the missing xml id at [3], resulting in a ValueError.
Similarly, when the receivable account is missing, the execution also fails, leading to a TypeError.

**Fix:**
This commit updated the tax group search condition to include both `tax_payable_account_id` and `tax_receivable_account_id`. Also, added skipping further processing if the related tax group is not found.

[1] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L47-L49
[2] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L115-L146
[3] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L164

sentry-6932155430

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

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#237305
Forward-Port-Of: odoo/odoo#224180

**Steps:**
- open documents in list view in dark mode
- select and deselect a record

**Observation:**
- the selected record's background becomes white and text was already white
- hence nothing can be seen clearly

**Cause:**
- Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode

https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36

[1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7

**Fix:**
- instead of hardcoding color, we use already available variable, which adjust the color, according to theme.

**Before:**
<img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" />

<img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" />


<br><br>
**After:**
<img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" />

<img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" />


opw-5261669

Forward-Port-Of: odoo/enterprise#100114

**Steps to reproduce:**
- Make a quotation in the Sales module
- Go to PoS, click Quotation/Order and select your quotation
- Select Settle the order
- Go through with the payment
- Go back to the Quotation in the Sales module
The Status widget still shows Quotation instead of Sales Order

**Why the fix:**
Since 18.3, the sale_order.state was not updated anymore when the state changed through the PoS.

This happened because we would only change the sale_order state if there was a downpayment involved. In 18.2, we
always recomputed the sale_order that was linked to the order we are currently settling.

The way it is done now is part of the same way it was done in 18.2 and before, meaning we add the linked sale_order
regardless of downpayments.

In 18.2, we did an action_confirm on the selected  sale_orders, but doing that in 18.3 will create another picking for this sale_order. This is not what we want as the picking is now handled and created by the PoS. 

This fix will just put the related sale orders in the "sale" state, so that users can no longer confirm it in the sales modules, which would create a second picking and create duplicates.

opw-5033979

Forward-Port-Of: odoo/odoo#237213
Forward-Port-Of: odoo/odoo#226008

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

Forward-Port-Of: odoo/odoo#237411
Forward-Port-Of: odoo/odoo#236454

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