Component of Odoo task: https://www.odoo.com/odoo/project/1105/tasks/2946044

Currently, the server reload option (through the `server_phoenix`
mechanism) activated by sending a SIGHUP signal to the main process.
This came with a consequential downtime while the server was restarting.

This commit changes it to reload the server with no downtime (POSIX +
Prefork mode)

When a SIGHUP signal is sent to the main server, it will now 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.

(+ a couple of small fixes)

Previous Behaviour:
- Snippets existing in the website module could only be added to pages of a website when generated via website  configurator.
- Manifest of all themes have their own `configurator_snippets` that defines what snippets will be rendered on the pages.

Expected Behaviour after the PR is merged:
- Snippets existing in other modules such as `website_sale`, etc. can now add their snippets to the pages via website configurator.
- Previously these snippets could only be used via drag & drop method from the editor after the website is already generated.

For adding non-website snippets into the pages of website:
- For website snippets, names can be given directly like `s_text_image`, etc. but for non-website snippets, the module prefix is required. (e.g., `website_sale.s_dynamic_snippet_products`).
- Module specific snippets can be defined in their own module's manifest(for default theme) and in the theme's manifest as addons to `configurator_snippets` like:

```
  'configurator_snippets_addons': {
        'website_sale': {
            'homepage': [
                ('website_sale.s_dynamic_snippet_products', 'after', 's_cover'),
            ],
        },
    },
```
  - `s_cover` is the reference snippet existing in the above `configurator_snippets` and `'after'` is the position, hence the `s_dynamic_snippet_products` will be rendered on the homepage after the `s_cover` snippet.
  - If `'after'` is replaced with `''` then the snippet will be appended before the reference snippet.

For default configuration:
- Dynamic snippets need some default values such as filter-id, template-key, etc. to load completely.
- All required default values for a snippet to render should be defined in the const file existing in the module where snippet exists under `SNIPPET_DEFAULTS` - like:

```
SNIPPET_DEFAULTS = {
    'website_sale.s_dynamic_snippet_products': {
        'filter_xmlid': 'website_sale.dynamic_filter_newest_products',
        'template_key':
            ('website_sale.dynamic_filter_template_product_product_products_item'),
        'data_attributes': {
            'snippet': 's_dynamic_snippet_products',
            'carousel-interval': '5000',
            'product-category-id': 'all',
            'number-of-elements': '4',
            'number-of-elements-small-devices': '2',
            'show-variants': 'true',
        },
    },
}
```
For theme-level snippet customization:
- Snippets in themes may require customizations to match with theme standards, for that we can define them in theme's manifest like:

```
'theme_customizations': {
    'website_sale.s_dynamic_snippet_products': {
        'data_attributes': {
            'number-of-records': '7',
            'carousel-interval': '3000',
        },
        'background': {
            'color': 'o_cc3',
            'shape': {
                'data-oe-shape-data': '{"shape":"web_editor/Wavy/07","flip":["x"]}',
                'element': """<div class="o_we_shape o_web_editor_Airy_07_001">""",
            },
        },
    },
}
```

task-4502087

Co-authored-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/8ee7677ba [REL] 18.5.0-alpha.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/38658ed81 [IMP] dashboard: sort pivot from headers [Task: 4543812](https://www.odoo.com/odoo/2328/tasks/4543812)
https://github.com/odoo/o-spreadsheet/commit/ccd7efa1d [REF] pivot: move sorting detection to getters [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/90bd67c89 [IMP] collaborative: more robust readonly [Task: 4543812](https://www.odoo.com/odoo/2328/tasks/4543812)
https://github.com/odoo/o-spreadsheet/commit/5b706da6f [FIX] composer: fix import from lib [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/318e3b619 [IMP] demo: add new data generator [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/fe37c4661 [FIX] borders: Recompute borders on `SET_BORDERS_ON_TARGET` [Task: 5024825](https://www.odoo.com/odoo/2328/tasks/5024825)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Following up on the quick merge of the voip transcription aa5983efc390dc16cff3ee99a55a8878d6e06939 
We are improving its state by modifying:

**Controller**: doesn't raise errors anymore, returns http err codes, keeping transcription_status persist errors (ref.1)
**Tests**: added backend controller tests and cron tests covering happy paths and edge cases. (ref.2)
**Summary**: added one_liner_summary filed on the voip call, which is generated after successful transcription; (if it fails we still have transcription)
**Banner**: Previously we informed user about the transcription_status with a selection field in a view. Now it is replaced by a status banner at the top of the form view
**Demo**: added some demo calls to showcase calls in all transcription_status.


(ref.3)



(ref.1) Without it: when we have an error in the request to transcribe it will rollback the transaction. Example: Controller is asked to transcribe, it can't because the file is too big, so it sets transcription_status=too_big_to_process **and raises**. This revers the transaction resulting in transcription_status set to pending. BAD

(ref.2) To avoid gymnastic of creating second cursor for the sake of testing cron try to commit, we restrict committing so it doesn't happen in the test_mode. 

Subsystem testing covers those
<img width="1139" height="408" alt="image" src="https://github.com/user-attachments/assets/90736892-58ce-4a15-b28d-bb8bf4369888" />

Current issue:

Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list.
Alice chooses the pivot dimensions based on the columns headers, which are the translated(!) field display names.

Now Bob opens the spreadsheet.
=> the pivot doesn't work because the dimension are specified using the field names in English, but they cannot be found because they are in French in the spreadsheet.

The issue is that `ODOO.LIST.HEADER` returns the translated field string. One solution would be drop `ODOO.LIST.HEADER` completely and just hard-code the string values when the list is inserted.
But users use it to add fields after, and then auto-fill it. Also, being easily able to know which cells are list headers is helpful to display "widget" like the sorting widget (task 4543812)

Other thing to consider: currently, when users are creating their own spreadsheet/dashboard, there's a mix of languages: what they manually type in cells, in their language (untranslated obviously) and the result of ODOO.LIST.HEADER, which is translated.

Task: 4805206

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

## Short functional explanation of the error
For Dutch companies, when downloading the NLCIUS file of an invoice, the schemeID of the companyID in the XML isn't correct.

## Reproduction Steps
1. Make sure you use a dutch company: in apps, download the 'l10n_nl' and 'account_edi_ubl_cii' modules. Then, click on your company and select the NL Company.
2. Go to settings and type Peppol. Under Customer Invoices, check the Peppo format. Then, setup a Peppol Endpoint. Hit save.
3. Go to the Accounting app and click on the customers tab, then invoices. Click on new.
4. Select a customer. Make sure that the customer is from the Netherlands, has an email address, and in the accounting tab, an account number. Still in the accounting tab, under Electronic Invoicing, set the format at NLCIUS, set a Peppol e-address and a Peppol Endpoint that is 20 characters long.
5. Add a product, click confirm then Send & Print. Make sure that NLCIUS is well checked and click again Send & Print.
6. In the bottom right corner of the page, just under the Amount Due, there's a paper clip icon. Click on it and you'll see the XML. Download it.

### Expected behavior
As the CompanyID is 20 characters long, the schemeID next to the CompanyID should have the value of 0190.

### Unexpected behavior
If you scroll a bit, you'll see that the SchemeID next to the CompanyID has a number of 0106.

## Origin of the issue
In the code, the SchemeID will have a value of 0190 if the CompanyID is 9 characters long.

__
opw-4943262



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

Forward-Port-Of: odoo/odoo#223431
Forward-Port-Of: odoo/odoo#219424

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

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

Forward-Port-Of: odoo/odoo#224044
Forward-Port-Of: odoo/odoo#215615

Currently, an error occurs when a new user with the Member role and Administrator rights for the Point of Sale app attempts to open POS Category.

Steps to reproduce:
---
- Install the `point_of_sale` module (without demo data).
- Create a new User and give Administrator rights for POS & Accounting
- Now log in with a new user in a different browser
- Open the pos session(Clothes or bar)

Traceback:
---
```py
AccessError: You are not allowed to modify 'Product Category' (product.category) records.

This operation is allowed for the following groups:
	- Products/Admin en Products / Create

Contact your administrator to request access if necessary.

ParseError:while parsing /home/odoo/src/odoo/saas-18.3/addons/point_of_sale/data/scenarios/clothes_category_data.xml:5, somewhere inside <record id="product_category_clothes" model="product.category">
            <field name="name">Clothes</field>
        </record>
```

This commit prevents the error by displaying an "Access Denied" pop-up when a user with the "Member" role and Administrator rights attempts to open the POS Category.

sentry-6683335275, 6679363278, 6823710988

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

Forward-Port-Of: odoo/odoo#224656
Forward-Port-Of: odoo/odoo#215429

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

This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally require tracking (no lot/serial), but have been updated later to require it.

When unbuilding such a product, `stock.move.line._action_done` currently raises a UserError requiring a lot/serial number, because the component moves created by `mrp.unbuild`:
- do not have a picking_type_id,
- are not inventory moves,
- are not scrap moves,
- and lack lot/serial information.

However, in this context, the lot requirement is misleading, as the original `mrp.production` did not generate tracked components. It is valid to restore untracked components even if they are now tracked.

**Current behavior before PR:**
- Create an `mrp.production` for a product with untracked components.
- Complete the production.
- Later, enable lot tracking on one or more of the original components.
- Attempt to unbuild the production.
- ❌ Error is raised: “You need to supply a Lot/Serial Number for product…”

**Desired behavior after PR is merged:**
- The unbuild operation proceeds without error.
- The untracked components are restored correctly.
- Behavior remains unchanged for tracked components that did require lot info during the original MO.



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

Forward-Port-Of: odoo/odoo#222612
Forward-Port-Of: odoo/odoo#217282

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

Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.

Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.

Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.

Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.

In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.

As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668

Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
    - This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
    - `property_product_pricelist` shouldn't get synced by itself
    - `specific_property_product_pricelist` is already included by the base method

opw-4988736

Forward-Port-Of: odoo/odoo#224133
Forward-Port-Of: odoo/odoo#222223

**Issue**:
* Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in balance_pymes_line_12500_sub_balances formula


**Root Cause**:
* Account codes 551 and 5525 were included in BOTH:
  1. Line 12500 sub_balances (unfiltered account_codes expression)
  2. Line 12500 sub_debits (domain expression with sum_if_pos filter)
* This double-counting within the same line caused financial investment amounts 
  to appear twice in the balance sheet
  
**How to Reproduce**:
1. Create Spanish company with 'es_pymes' chart of accounts
2. Post journal entries to accounts 551 or 5525 (current financial investments)
3. Generate 'Balance Sheet - SMEs (ES)' report
4. Observe amounts in line 'V. Current financial investments' are exactly 
   doubled compared to account balances
5. Click on the doubled amount - shows underlying transactions sum to half the amount

**Fix**:
* Removed account codes 551 and 5525 from balance_pymes_line_12500_sub_balances
* These accounts are properly handled by the  sub_debits expression
* Each account is now counted only once within the line
  
opw-4983300

Forward-Port-Of: odoo/enterprise#93052

Current issue:

Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list.
Alice chooses the pivot dimensions based on the columns headers, which are the translated(!) field display names.

Now Bob opens the spreadsheet.
=> the pivot doesn't work because the dimension are specified using the field names in English, but they cannot be found because they are in French in the spreadsheet.

The issue is that `ODOO.LIST.HEADER` returns the translated field string. One solution would be drop `ODOO.LIST.HEADER` completely and just hard-code the string values when the list is inserted.
But users use it to add fields after, and then auto-fill it. Also, being easily able to know which cells are list headers is helpful to display "widget" like the sorting widget (task 4543812)

Other thing to consider: currently, when users are creating their own spreadsheet/dashboard, there's a mix of languages: what they manually type in cells, in their language (untranslated obviously) and the result of ODOO.LIST.HEADER, which is translated.

Task: 4805206

### Steps to reproduce:
	- Install Planning app
	- Create a portal user and an employee for this user
	- Create a shift for this user and Publish it
	- Go to the email that has been sent and click on View Your planning
	- Notice you are redirected to the portal dashboard home

### Cause:
Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my

https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26

### Fix:
We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view

opw-5045746

Forward-Port-Of: odoo/enterprise#93359
Forward-Port-Of: odoo/enterprise#93333

### Steps to reproduce:
	- Install Helpdesk, Sale Subscription apps
	- Create a service recurring product and set its invoicing policy as 'Based on Timesheets'
	- Create a SO with the created product and set the qty to 0
	- Create a Helpdesk ticket and link it to the SO
	- Record some timesheets in this SO
	- Run the cron for generating recurring invoices
	- Notice no invoice will be created for the SO and it will be considered as free renewal

### Cause:
When trying to create a recurring invoice we check if the invoice that will get generated is free by checking the MRR and the total amount of the SO and if one of them are 0 we will flag this invoice as free so we won't generate it

### Fix:
We check if the order lines to be invoiced is invoiced based on delivery and they have delivered quantity already and if so we create the invoice even if the MRR and the total amount is equal 0

opw-4990478

Forward-Port-Of: odoo/enterprise#93245
Forward-Port-Of: odoo/enterprise#93115