Steps to produce:
---
- Install `Databases` modules.
- Go to project > Switch to list view and open project.
- Click on the gear icon > Click `Edit Properties.`

Observation:
---
- Clicking `Edit Properties` does nothing.

Root cause:
---
- The `Edit Properties` action appears whenever a properties field is present in the view.
- Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]).
- Here at [2], the field is added in `edit_project` view.
- However, the field is only visible when `database_hosting` is set, and its value is different from `other`.

Solution:
---
- Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`.

[1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36
[2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158

Note:
---
- Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing.
 We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only.

opw-5933007
---

Forward-Port-Of: odoo/enterprise#108056

When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
  
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
    
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
    
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
    
Examples:
    
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
    
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.

Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)

task-6026748

Forward-Port-Of: odoo/enterprise#110410

**Steps to reproduce:**
* Install  `point_of_sale` module.
* Go to Settings:
     * Enable Lots & Serial Numbers.
     * Enable Variants.
     * Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
     * Enable Track Inventory set to By Lots.
     * Under Attributes & Variants:
     * Add an attribute with two values and save.
* Generate product variants:
     * Open one variant and set barcode to 5123648695416.
* Update inventory:
     * Go to the main product (template).
     * Update On Hand Quantity:
             * Update On Hand Quantity with a lot/serial number:
               010512364869541610784512.
             * Select the variant with the defined barcode.
* Under Point of Sale tab:
    * Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.

**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
  *TypeError: Cannot read properties of undefined (reading
  'product_template_attribute_value_ids')*.

**Cause:**

[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│    • product = await _getProductByBarcode(productBarcode)  ✅ found
│    • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│                                                              ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│    • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│    • calls openConfigurator(productTemplate, { ...opts })
│      opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
     • opts.code = lotBarcode  → truthy → enters if(opts.code) branch
     • getBy("barcode", opts.code.base_code)
     •  getBy("barcode", "784512")   ← "784512" is a LOT number, not a product barcode!
       → returns undefined ❌
     • product packaging lookup also fails → undefined ❌
     • product = undefined
     │
     └─ attributeLinesValues.map(values =>
            values.filter(value =>
                product.product_template_attribute_value_ids.includes(value)
                ^^^^^^^ undefined  → 💥 TypeError

**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
  instead.

---

opw-6031909

Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572

Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements).

This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource.

This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements.

Steps to reproduce:
- Open website builder on a product page
- Select text in "Add to cart" button
- Copy
- Paste
- Bug: a `p` element is created

(on master)
- Open website builder
- Select "Company" below footer
- Copy
- Paste
- Bug: a `p` element is created

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5868460

Forward-Port-Of: odoo/odoo#257512
Forward-Port-Of: odoo/odoo#247231

When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default context whitelist. This causes the new project to inherit the template's company instead of the lead's company, resulting in a company mismatch with the partner and a UserError.

https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/crm_sale_project/models/crm_lead.py#L37-L45

https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/project/models/project_project.py#L1413-L1419

Steps To Reproduce:
1. Go to CRM, create or open a lead.
2. Clear the contact field and save.
3. Click the gear icon → Create Project.
4. Select any project template (not empty) and submit.

Ticket [link](https://www.odoo.com/odoo/project.task/5933253)
opw-5933253

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

Forward-Port-Of: odoo/odoo#250087

Issue Before This Commit:
=======================
When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users.

Steps to Reproduce:
=======================
- Install the `Purchase` app.
- Go to Purchase and select multiple RFQs in the list view.
- Click `Send by mail` from the actions menu.
- Select the RFQ email template and send the email.
- Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view.

Cause of the issue:
=======================
The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated

After This Commit:
=======================
When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state.

TaskID-5443248

Forward-Port-Of: odoo/odoo#243050

Currently, an error occurs when a user submits the Create a Task form.

**Steps to Reproduce:**

 - Install the `website_project` module.
 - Go to `website` > `Click on Edit` > `Drag and drop` form.
 - Click on the form and, set the action to `Create a Task`, then save.
 - Fill in the required data in the form.
 - In the `Email Address` field, enter an email that does not correspond to any 
   existing partner.
 - `Submit` the form, and the `error appears in the logs`.

`ValueError: Invalid field 'email_cc' in 'project.task'`

With this [recent commit], the email_cc field has been removed from project.task, along 
with the mail.thread.cc inheritance, because threads are now able to find CC recipients. 
so, when user submits the form with an email address that does not correspond to any 
existing partner, the system adds email_cc to the record [1], and when it attempts to 
create the record [2], it raises an error.

This commit ensures that email_cc is no longer added to the record.

[recent commit]: https://github.com/odoo/odoo/commit/3c26c0553754a75d9440097ad473be3cc8bcb320#diff-93ba226020add6481cfeab916e69980a59163e2925a5c2c9a3bc0aaceb484cdf

[1]- https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/website_project/controllers/main.py#L61

[2]: https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/project/models/project_task.py#L1167

sentry-7374084515

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

Forward-Port-Of: odoo/odoo#256964