Steps to reproduce:

1. Create a maintenance request with these values:

   * Maintenance Type: Preventive
   * Recurrent: enabled
   * Repeat Every: 1 day, forever
   * Scheduled Date: today
2. Confirm that an activity is created for the responsible user.
3. Mark the activity as done.
4. Move the request to `Repaired`, or another done stage.
5. Check the newly generated request in the recurring series.

When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series.

The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`.

Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request.

The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request.

Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request.

opw-6409396


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

Forward-Port-Of: odoo/odoo#279470

Steps to produce:
---
- Install website_sale module without demo.
- Create a new product and publish it.
- From the incognito, go to shop and add that product to cart.
- While doing checkout > fill the address form.
- Add the all details including the company name and valid VAT.
  (ex. BE0477472701)
- Submit the form.

Issue:
---
- When a public or guest user submits a new address with both a contact name
  and a company name along with a valid VAT number, the contact's name was
  being overwritten with the company name.

Root cause:
---
- The _compute_is_company heuristic in res.partner automatically sets
  is_company=True for partners with valid VAT. In [commit]
  `_create_or_update_address`, the condition `elif partner_sudo.is_company:`
  was designed to rename existing companies, but incorrectly caught newly
  created individuals marked as companies due to VAT, causing their name to be
  overwritten instead of creating a parent company.

Solution:
---
- Replaced the is_company check with explicit conditions: the partner
  has no parent_id, has contact-type child_ids.
- This ensures the rename-company branch only fires for actual company
  heads that the logged-in user belongs to, not for individuals that
  happen to have is_company=True due to a valid VAT.

[commit]: https://github.com/odoo/odoo/commit/8f3a32170c842f5f42edc79bf8620276f0da7be4

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

When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language.

Steps to reproduce
==================
1. Set a language other than English as the website default language.
2. While your user language is English, create a helpdesk team with the website form enabled.
3. Open the team form on the website.

=> The form is rendered in English instead of the website language.

Root cause
==========
`_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view.

Fix
===
Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language.

opw-6303903

Forward-Port-Of: odoo/enterprise#129265
Forward-Port-Of: odoo/enterprise#121164

**Description of the issue/feature this PR addresses:**

When using the POS in dark mode, certain form control elements display
black text on a dark background, making them illegible.

This occurred because the POS application lacked the `color-scheme` CSS
property. While the backend web client correctly applied this property,
its absence in the POS meant the browser still assumed a light theme, 
forcing default User Agent styles (black text) onto native form controls 
that escaped standard view helpers.

This commit resolves the issue by applying the `$o-webclient-color-scheme`
variable to the POS application. This signals the browser to render form
controls and UI elements based on the current web client color scheme,
ensuring text remains legible within the POS app.

**Steps to reproduce:**

- POS > Open Restaurant Register
  - Hamburger icon (top right) > Switch to Dark Mode
  - Register > vertical ellipses icon (bottom left) > Quotation/Order > type in the search bar > observe black text on dark grey background


**Current behavior before PR:**

<img width="1911" height="588" alt="Before 1" src="https://github.com/user-attachments/assets/99581745-23eb-45e1-96f7-bca78853369c" />
<img width="1919" height="550" alt="Before 2" src="https://github.com/user-attachments/assets/b7eb9726-e2d2-492b-ad2b-6c0cc6613bb8" />

**Desired behavior after PR is merged:**

<img width="1910" height="433" alt="After 1" src="https://github.com/user-attachments/assets/419b7a2a-234e-47c8-854e-22adf6a7c5c1" />
<img width="1915" height="513" alt="After 2" src="https://github.com/user-attachments/assets/8f1cf5c9-5ad1-4aac-9879-840d6d9d537e" />

opw-6508945

Forward-Port-Of: odoo/odoo#284831