Before, the only reload option that existed was the `server_phoenix`
mode that reexecuted the server upon receival of the SIGHUP signal.
This came with a consequential downtime while the server was restarting.

We add the option that allows to reload the server with no downtime, by
adding the environment variable

ODOO_GRACEFUL_RELOAD=1

(POSIX + Prefork mode)

With this environment variable is set and a SIGHUP signal is sent to
the main server, it will initiate the shutdown procedure in a separate
process that will first wait until the main process has finished
restarting and is ready to handle new incoming HTTP requests.

The reexecuted server will reuse the same socket and notify its stopping
fork with a SIGHUP signal, which will then proceed with the graceful
shutdown procedure. It will not be able to reap the children processes,
so it will monitor them closely in a slightly different way using
psutil. The newly restarted server will reap them without consequence.

Note: the gevent longpolling server is not handled gracefully.

(This comes along with 2 small fixes.)

## Description

Law no. 30-26 of June 18, 2026 updates Dominican ISR withholdings effective **July 1, 2026**:

- **Professional services, fees, commissions, and rentals paid to individuals:** 10% to 15%.
- **Specific foreign-payment categories:** 15% for royalties or rights, software licenses, online advertising, and the use or storage of data.
- **General remittances abroad:** remain at 27% when they are outside those specific categories.

The DGII's current **IR-17-2026 (July 2026 onward)** also confirms that the concepts discussed in review are three distinct reporting rows:

- **Row 4 — Transfers of titles and properties:** 2%.
- **Row 17 — Other income under Decree 139-98, Article 70(a)/(b):** 3%.
- **Row 18 — Other withholdings under General Rule 07-2007, as amended by Law 30-26:** 3%.

The two 3% rows must not be conflated with each other or with the separate 2% transfer withholding.

## Implementation

The changed-rate template entries use new, rate-explicit XML IDs, as recommended in review:

- `ret_15_income_person`: new -15% fee withholding, replacing `ret_10_income_person` in the template; posts to `21030301`.
- `ret_15_income_rent`: new -15% rental withholding, replacing `ret_10_income_rent` in the template; posts to `21030302`.
- `ret_3_income_person`: new -3% General Rule 07-2007 withholding, replacing `ret_2_income_person` in the template; posts to `21030308`.
- `tax_group_person_services_15`: new grouped tax using `ret_15_income_person`.
- `tax_group_person_construction_3`: new grouped tax using `ret_3_income_person`.
- `position_person_services_15`: new physical-services fiscal position mapped only to the current 15% grouped tax.

The remaining legal concepts stay separate:

- `ret_3_income_article_70`: new -3% tax for Decree 139-98, Article 70(a)/(b), posted to `21030309`.
- `ret_2_income_transfer`: remains at -2% on `21030306`; its misleading “Materials” source metadata is corrected to transfers of titles and properties.
- `ret_27_income_remittance`: remains active at -27% on `21030307`, with the general foreign-services fiscal position unchanged.
- `ret_15_income_foreign_royalties_technology`: new -15% tax only for the foreign categories covered by Law 30-26. It posts to the new `21030310` Law 30-26 payable account rather than the L253-12 remittance account.
- `position_exterior_royalties_technology`: new fiscal position mapping purchases only to that specific 15% tax.

The specific foreign tax keeps the short invoice label `-15% ISR (L30-26)` to avoid wrapping in vendor-bill PDFs.

The original manifest author entry is unchanged, as requested. The Git history and corporate CLA record this contribution by Grupo de Consultoria Henca.

### Existing-company reload behavior

The superseded 10%/2% tax, grouped-tax, and physical-services fiscal-position rows are removed from the template rather than shipped as obsolete entries to new companies.

On an existing company, Odoo's chart reload keeps those historical records and generated XML IDs unchanged, then creates the new current-rate records under the new XML IDs. On a newly loaded chart, only the current template entries are created.

The physical-services fiscal position also has a new XML ID intentionally. Reload preserves existing fiscal-position mappings as user-configurable data and only appends mappings involving new taxes; reusing `position_person` could therefore leave both the historical and current destinations on one position. `position_person_services_15` keeps the current mapping isolated while the old position remains available for historical operations.

`ret_2_income_transfer` keeps its existing XML ID because its legal rate, concept, and account remain 2% / transfers / `21030306`. The corrected label is present for new charts; backfilling label-only metadata on already-loaded charts would require an explicit upgrade migration because standard chart reload does not rewrite that user-visible metadata.

## Official references

- DGII, current IR-17-2026 download page (July 2026 onward): https://dgii.gov.do/herramientas/formularios/formularioDeclaraciones/Paginas/impuestosRetencionesyRetribuciones.aspx
- Law 30-26: https://www.consultoria.gov.do/Consulta/Home/FileManagement?documentId=3405887&managementType=1
- DGII implementation calendar, notice 10-26: https://dgii.gov.do/publicacionesOficiales/avisosInformativos/Documents/2026/10-26.pdf
- DGII CA59, calculation for professional and technical services: https://ayuda.dgii.gov.do/conversations/retenciones-y-retribuciones-complementarias/ca59-qu-porcentaje-del-isr-deben-retener-las-personas-jurdicas-a-las-personas-fsicas-en-la-prestacin-de-servicios/5f3c175f8cd858ce879a130f
- DGII clarification for General Rule 07-2007 and the construction sector: https://ayuda.dgii.gov.do/conversations/discusiones/aplicacin-de-la-ley-nm-3026-respecto-a-la-retencin-prevista-en-el-artculo-3-de-la-norma-general-072007-sector-construccin/6a45792cde3c6003da189ff1
- DGII legal basis for the 2% transfer withholding: https://ayuda.dgii.gov.do/conversations/discusiones/base-legal-retencion-2-transferencia-de-titulos-y-propiedades/5f6355928cd858ce872bb35a
- Ministry clarification on the specific foreign technology and royalty categories: https://www.hacienda.gob.do/ley-30-26-no-dispone-impuestos-por-suscripciones-de-ciudadanos-a-plataformas-digitales-reduce-de-27-a-15-la-retencion-a-empresas-que-contratan-servicios-tecnologicos-en-el-exterior/

Legal basis cited by DGII: Law 11-92, article 309, as amended by Law 30-26, article 17; Regulation of Title II of the Tax Code, article 70.

## Validation

- The branch is rebased on the current 17.0 head and contains one squashed commit.
- The account, tax-template, and fiscal-position CSV files have consistent column counts, unique IDs, and valid child/account references.
- A fresh Dominican chart contains only the new current-rate IDs; the superseded template IDs are absent.
- The fresh chart was verified with fees/rentals at 15%; General Rule 07-2007 at 3% on `21030308`; Article 70(a)/(b) at 3% on `21030309`; transfers at 2% on `21030306`; general remittances at 27% on `21030307`; and the covered foreign categories at 15% on `21030310`.
- The 15% services and 3% construction groups contain exactly the current tax children, and the new services fiscal position maps each purchase tax to only the 15% group.
- An existing company loaded from the pre-law template was reloaded twice. Its historical 10%/10%/2% taxes, historical groups, and historical fiscal position retained their original record IDs and configuration; all current records were created once; the old and new positions each retained exactly two isolated mappings; and the second reload was idempotent.
- `/account:TestChartTemplate`: 22 tests passed, 0 failures, 0 errors.

This is the first contribution by Grupo de Consultoria Henca (https://www.consultoriahenca.com); the corporate CLA signature is included in `doc/cla/corporate/consultoriahenca.md` as instructed by `doc/cla/sign-cla.md`.

Forward-Port-Of: odoo/odoo#280127
Forward-Port-Of: odoo/odoo#275986

Steps to reproduce the bug:
- Create and Confirm a purchase order with any product and a description (name) on the order line
- Try to edit the description (name) field

Problem:
The description field was not editable on a confirmed purchase order when the product_id column was visible, but became editable when product_id was hidden.

The `ProductLabelSectionAndNoteField` widget renders both `product_id` and the description (`name`) in a single cell. When `props.readonly` is true (because `product_id` has `readonly="state in ('purchase', 'to approve', 'done', 'cancel')"`) and the order state is not draft (`isProductClickable` is true), the template rendered the description textarea with a hardcoded `readonly="1"` attribute, making it impossible to edit regardless of the actual intended readonly state for the description.

When `product_id` was column-invisible, the `name` field rendered via its own `section_and_note_text` widget, which correctly used `sectionAndNoteIsReadonly` (blocking only `cancel`, `done`, `posted`) hence the inconsistency.

Solution:
Replace `readonly="1"` with `t-att-readonly="sectionAndNoteIsReadonly"` on the description textarea so its editability follows the same logic as the other cases: blocked only for terminal states (`cancel`, `done`, `posted`), not for `purchase` or `to approve`.

opw-5474986

Forward-Port-Of: odoo/odoo#272102

Steps to reproduce:
1. Create a new DB without demo data.
2. Go to Accounting Dashboard.
3. Click on the 'Tax Returns' card.
4. Input the date and click 'Apply'.

Before:
Since saas-18.3, the post-init hook only iterated over companies with a chart_template defined. In databases created without demo data, the default company had no chart_template set at post-init, so `_initiate_account_onboardings()` was never called. This prevented the creation of an `onboarding.progress` record for the accounting dashboard. When clicking the 'Tax Returns' button, it attempted to access the onboarding progress but found none, raising a `ValueError: Expected singleton`.

After:
We now iterate over all companies and only guard `_get_tax_closing_journal()` behind the chart_template check. This ensures that even companies without a localization chart template (such as the default company in a fresh database without demo data) will have their onboarding progress correctly initialized, avoiding the crash on the accounting dashboard Tax Return button.

### [FIX] charts: avoid conflicting click listeners

We have several click listeners on charts: one on the legend, one on all
odoo chart elements, and one on the chart itself in dashboard. The
first two are handled in ChartJS, and the last one is handled in a
`t-on-click`.

The problem is that the `t-on-click` was called for every click on the
chart, even if the click was on the legend. This is because ChartJS
handles events at the next animation frame, so the `t-on-click` was
always called before the ChartJS click listener.

To fix this, we also handle the click on the chart inside ChartJS.

The middle mouse click was also handled when clicking on the chart to open its linked menu, but not when clicking on an element of  the chart(eg. bar of odoo bar chart) chart.

Task: [4636147](https://www.odoo.com/web#id=4636147&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)




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

The website header fullwidth option and the eCommerce shop content fullwidth option were merged at different times and currently behave differently on large screens, causing noticeable misalignment between the header and content.

The header option only applies a container-fluid class, while the shop option goes further by adjusting padding for XL to prevent content from appearing too "stuck" to the edges of the screen. When both options are active, this creates visual inconsistency.

Furthermore, since website_sale had its own container-fluid padding logic while the rest of the website handled it differently, this led to inconsistencies.

This commit establishes a consistent container-fluid padding system across the entire website that applies to headers, snippets, page layouts, and any other components using container-fluid class.

It also updates (in website_sale) some conditional sidebar padding logic to handle presence/absence of sidebar, removes unnecessary container padding, and refines variables for better maintainability.

The solution provides unified spacing behavior whether container-fluid (fullwidth option) is used in headers, eCommerce layouts, snippet content, or page layout, eliminating visual inconsistencies.

task-4840034

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

Description of the issue/feature this PR addresses: 
'Member' users can use the AI field button when the prompt contains standard field references. When the prompt contains a Studio field reference, there is an error message stating 'email template editor' access is required.

Current behavior before PR:
-Create an internal 'Member' user
-Add a 'user' group for the app you want to test on (bug spotted in Helpdesk). 
-Make a plain text Studio field
-Make a text AI field where the prompt references the plain text Studio field you just created.
 -Make a text AI field where the prompt references a standard available field. 
-Log into the database as the 'Member' user
-Push the 'AI' button on each of the two fields you created.
 -The one referencing the standard field should populate as normal; the one referencing the Studio field will trigger an error message asking for 'Email template editor access'.

Desired behavior after PR is merged:

Allowing AI fields unrestricted rendering to avoid the access error when the studio field is used in the prompt.

Task-5016767





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

Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history.

Steps to reproduce:
- Have mitchell admin receive notification in Odoo
- Install `mail_group`
- Wait a few seconds to receive following user_notification from mail group:
```
on My Company News
Hello,
You have messages to moderate, please go for the proceedings.
```
- Go to related record then delete it
- Go back to inbox or history

=> One of them show `An error occurred while fetching messages.`

This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications.

`mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with:
```
MissingError: Record does not exist or has been deleted
```

This commit fixes the issue by doing its best to show message even when the related record has been deleted.

opw-4546920

Issue before this commit:
=========================

When generating a lot number for a Drawer/Flipover and
validating the operation, a traceback is raised:
"ValueError: Expected singleton: ir.sequence()"

Steps to Reproduce:
=========================
- Install the "stock" module.
- Create a receipt for the drawer product.
- Open the detailed operations wizard.
- Click on "Generate Serials/Lots".
- Enter the first lot/serial number. Validate it.

Result: A traceback is raised with: ValueError: Expected singleton: ir.sequence()

Cause of the issue:
=========================

The 'lot_sequence_id' field is defined in the 'stock' module with a default
value. However, defaults are only applied at record creation time.

When the drawer is initially created by the product module, the
lot_sequence_id field does not exist yet. Later, when the stock module is installed,
the existing drawer is configured to be tracked by lot via demo data.

Since the drawer already exists, the default value for lot_sequence_id is
not applied, leaving the field unset.

The lot_sequence_id field is added in this [PR](https://github.com/odoo/odoo/pull/200395),
but the issue occurs on [the line](https://github.com/odoo/odoo/blob/saas-18.3/addons/stock/models/stock_move.py#L1026) introduced in [this PR](https://github.com/odoo/odoo/pull/240368).
The code attempts to call get_next_char() on lot_sequence_id while it is still unset (False),
resulting in the method being called on an empty recordset.

As a result, serial/lot number generation fails due to a missing sequence. Same issue for Flipover.
With This Commit:
=========================
Ensure that the existing drawer product tracked by lot is
assigned a default lot_sequence_id when the stock module is installed.
This guarantees consistent and correct lot generation for the drawer/Flipover.

1. record.toData() keeps markup of html fields

Before this commit, `record.toData()` was not retrieving the "markup" flag of html fields.

This is a problem because inserting this data would remove the `Markup` of these html fields, therefore showing html as text content in UI.

This commit fixes the issue by having `record.toData()` return `["markup", string]` rather than `string` on html fields that have markup content, so that insert preserves the markup.

2. broadcasted activity data is time-limited

When an activity has updated content in a tab, the activity data is broadcasted to all other tabs.

Before this commit, the broadcasted data was taken into account to other tabs, even if other tabs woke up much later.

This is a problem because tabs would feed old activity data, which leads to wrong discuss state. For example, the assignee of activity is also broadcasted to display avatar and name, and the assignee of activity may have outdated data like different name.

This commit fixes the issue by limiting the broadcasted activity data to other tabs in time to 3 seconds, so that other tabs do not feed from outdated data.

**Steps to reproduce:**
- Order a combo with some extra products
- The displayed total will be correct
- Go in the restaurant or the orders in the backend
- The total is not correct, some lines are in negative

**Problem:**
When ordering a combo in the self order, the displayed price will be correct, up until the payment where it is recomputed wrongly. This also affects the backend as this is the value that is used to save the order's price.

**Why the fix:**
In the frontend, everything is correctly computed, explaining why the correct price is displayed. But when going back to the backend to retrieve some data and to make sure that the product prices did not change, the data is wrongly computed. The _verify_line_price function is the one that changes the data.

This arises when we order some extras in the combo, so it seems the function was not changed when the combo's REF was done.

This fix was made by keeping the implemented logic to distribute the unit_price among the lines as it was done before, so it might be different from what is done in the frontend, but this is how it was done even before the combo's REF.

opw-4990886

#### Description of the issue this PR addresses:
- Color detection only checked the closest element of the selected text nodes, assuming the color is always applied on their direct parent.
- This is not always the case: the color can be applied on a `<font>` wrapping an inline element (e.g. a neutral style `<span>` created inside button links), or on the list item itself when its content is wrapped in a block (e.g. a heading).
- As a result, remove format could not remove such colors, and its toolbar button stayed disabled as no color was detected for the selection.

#### Desired behavior after PR is merged:
- Introduce the `closestColoredElement` util, which returns the element actually applying the color to a node by looking up its ancestors.
- The lookup stops on an element resetting the color of its content (`style="color: initial"`), as there is nothing to remove above it. It is also limited to the closest paragraph related element, or to the closest list item (color) or table cell (background color), as those can hold the color of a text nested deeper in them.
- Use it for the remove format detection, and to get the `<font>` to clean when removing a color: the closest one is not necessarily the one applying it, e.g. a `<font>` with a background color nested in a `<font>` with a text color.

task-6312677

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

Issue before this commit:
=========================

When generating a lot number for a Cabinet with Doors/Printer and validating 
the operation, a traceback is raised: "ValueError: Expected singleton: ir.sequence()"

Steps to Reproduce:
=========================
- Install the "helpdesk_stock" module.
- Create a receipt for the Cabinet with Doors product.
- Open the detailed operations wizard.
- Click on "Generate Serials/Lots".
- Enter the first lot/serial number. Validate it.

Result: A traceback is raised with: ValueError: Expected singleton: ir.sequence()

Cause of the issue:
=========================

The 'lot_sequence_id' field is defined in the 'stock' module with a default value. 
However, defaults are only applied at record creation time.

When the Cabinet with Doors is initially created by the product module, the 
lot_sequence_id field does not exist yet. Later, when the helpdesk_stock module is installed, 
the existing Cabinet with Doors is configured to be tracked by lot/serial via demo data.

Since the Cabinet with Doors already exists, the default value for 
lot_sequence_id is not applied, leaving the field unset.

The lot_sequence_id field is added in this [PR](https://github.com/odoo/odoo/pull/200395), 
but the issue occurs on [the line](https://github.com/odoo/odoo/blob/saas-18.3/addons/stock/models/stock_move.py#L1026) introduced in [this PR](https://github.com/odoo/odoo/pull/240368). 
The code attempts to call get_next_char() on lot_sequence_id while it is still unset (False), 
resulting in the method being called on an empty recordset.

As a result, serial/lot number generation fails due to a missing sequence. Same issue for the printer.

With This Commit:
=========================
Ensure that the existing Cabinet with Doors/Printer product, tracked by serial/lot is 
assigned a default lot_sequence_id when the helpdesk_stock module is installed. 
This guarantees consistent and correct lot generation for the drawer.

### Issue:
An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries
Some Italian banks reject SDD files containing this node

### Cause:
https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries
The original fix was intended for Nordea (Sweden) only, which requires this node explicitly
The assumption that other countries would accept it was incorrect

### Steps to reproduce:
- Install `account_sepa_direct_debit` and `l10n_it`
- Switch to the IT company
- In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042`
- Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount)
- Create and validate a Batch Payment with that payment
- Open the generated PAIN008 XML

Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present

opw-6530996

Forward-Port-Of: odoo/enterprise#130304