Currently, an error occurs when exporting an accounting report to 
PDF if any of the selected contacts do not have a name.

**Steps to reproduce:**
- Install the `account_reports` and `contacts` modules.
- Go to Contacts and open any contact (e.g., Azure Interior).
- Click `Add` > `Save & Close`, then `save` the contact.
- Navigate to Accounting > Reporting > Aged Receivable.
- Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`).
- Click `PDF` to export the report.

**Error:**
`TypeError: sequence item 0: expected str instance, bool found`

**Root Cause:**
At [1], `options['selected_partner_ids']` is built using `partner.name`, which may 
be `False` for unnamed contacts. At [2], the `partner_value` list may therefore 
contain `False` entries coming from `options['selected_partner_ids']`. When 
calling `', '.join(partner_value)`, an error is raised because the list contains 
`non-string` (`bool`) values.

**Fix:**
This commit prevents errors when exporting reports to PDF and ensures 
that partner names are displayed in the report the same way as in the 
partner selection widget.

[1]:
https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745

[2]:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93

opw-5467321

Forward-Port-Of: odoo/enterprise#105025
Forward-Port-Of: odoo/enterprise#103828

***Behavior:***
In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route,
and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components.

When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount.

***Steps to reproduce:***
- Create a second warehouse.
- Check Resuply From 'First Warehouse' (this will unarchive a route)
- Create a product that uses that route for reordering.
- Create a second product
- Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1
- In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route.
- Add any amount to reorder in 'Replenishment' then click the Order button.
- If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount.

opw-5351460

Forward-Port-Of: odoo/enterprise#101462

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

Forward-Port-Of: odoo/enterprise#104914
Forward-Port-Of: odoo/enterprise#103944

Scenario:

- Setup Unsplash and install website
- Set a user as "Website: Editor and Designer"
- Login as that user and go to any website page with a qweb view
- Go to edit mode and drop Text-Image in a view
- Replace the image with an unsplash image and then save

Result: the save fails without any message shown, and there is a
security access WARNING in the logs.

Note: a similar scenario can be done for a restricted editor that is
editing a HTML field it has write access to.

Issue: to save a model with res_id 0, we need to either be admin
(base.group_system) or the record creator. Since
9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype
neutering of happening, we create the attachment as SUPERUSER.

Then when we modify the attachment url (for unsplash images), we have no
access right to the attachment since we are not the creator.

Fix: create the attachment with the current user, and only use
SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't
have write access right to ir.ui.view, which in normal use case should
only happen for "Restricted Editor"). This way the image is created by
the user that uploaded it and not SUPERUSER.

opw-4850611
opw-5387258
opw-5489219

Forward-Port-Of: odoo/odoo#244831
Forward-Port-Of: odoo/odoo#219472

Currently, an error occurs when uploading `encrypted or incomplete` 
PDF files (missing EOF marker) while creating a quotation document 
header or footer.

**Steps to reproduce:**
- Install the `sale_pdf_quote_builder` module.
- Navigate to: Sales > Configuration > Headers/Footers.
- Upload encrypted file [1], or incomplete file [2].

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`PyPDF2.errors.PdfReadError: EOF marker not found`

**Root cause:**
At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly 
call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises 
an error.

**Fix:**
This commit prevents errors when users upload unreadable or encrypted PDF files.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11

sentry-6928220164
opw-5227601

Forward-Port-Of: odoo/odoo#245109
Forward-Port-Of: odoo/odoo#230712

**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.

This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.

**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.

**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.

task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)

Modules containing valid Markdown in their description or README.md could cause Odoo to crash during startup or module updates if the content confused the reStructuredText (RST) parser.

### Steps to reproduce

1. Create a module with a manifest like this:

    ```py
    {
        'name': 'base',
        'description': """
        ....
    """,
    }
    ```

2. Start the Odoo server or attempt to install or update update the module.
3. The server crashes:

    ```
    docutils.utils.SystemMessage: (SEVERE/4) Unexpected section title or transition.
    ```

### Cause

The crash occurs during the execution of the `_get_desc` method in the `ir.module.module` model, which computes the `description_html` field.

When Odoo processes a module, it checks for a pre-rendered HTML description at `static/description/index.html`. If this file is missing, the `_get_desc` method attempts to generate HTML from the module's `description` field (often populated from the `README.md` file) by calling the `docutils.core.publish_string` function.

The **docutils** library is designed specifically for **reStructuredText (RST)**. If the input text contains structural patterns that violate RST rules—such as inconsistent header levels or "transitions" in invalid contexts—docutils flags a severe error and raises a `docutils.utils.SystemMessage` exception.

### Fix

This commit handles these exceptions and falls back to a raw text rendering. It also improves the logic by removing the restriction that prevented non-application modules from rendering their description via RST.

opw-5424131

Forward-Port-Of: odoo/odoo#243517

**Issue**
Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected duration.

**Steps to reproduce**
1. Create two workcenters marked as alternatives (100% and 50% efficiency).
2. Create a BOM operation that produces 100 products with a 1h expected duration each, on the 100% workcenter.
3. Create and plan an MO using this BOM.
4. In Planning > Planning by Workcenter (Gantt), drag the workorder to the 50% efficiency workcenter. → Expected duration remains 100h instead of 200h.
5. Drag the same workorder back to the 100% workcenter. → Expected duration becomes 200h instead of 100h.

**Cause**
`date_finished` is recomputed in `write()` using the *previous* workcenter’s efficiency, because the duration calculation happens before the new `workcenter_id` is applied: https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L471

Since the Gantt progress bar uses the interval [`[date_start, date_finished]`](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L672C13-L674C107) to compute the expected duration (via `_web_gantt_progress_bar_workcenter_id`), the displayed duration becomes wrong.

opw-5224272

Forward-Port-Of: odoo/odoo#245002
Forward-Port-Of: odoo/odoo#239021