Currently, an error occurs when a portal user opens a `shared project` and tries 
to `mention(@)` someone in the chatter of a `new(unsaved) task`.

**Steps to produce:**

- Install the `project` module.
- Open the project app and create a new project with at least one task.
- From the project’s `dropdown menu(⋮)`, select `Share Project`.
- Add a `collaborator: Joel Willis`, with `Edit access` mode, copy the public link, 
  and click `Share Project`.
- Open the shared link in an incognito window and sign in as a portal user.
- Open the `project folder` > open any task > click `New` > type `'@'` in the chatter.

**Error**:
`ValueError: Expected singleton: project.task()`

**Root cause:**
The `composer(message box)` allows typing and mention suggestions even when 
the task record is not yet saved (`self.thread.id` is `undefined`). At [1], the method 
is called on an `empty` recordset, causing an `error`.

**Fix:**
This commit prevents users from writing in the chatter by stopping the composer 
initialization when the record(thread) is `unsaved`.

[1]:
https://github.com/odoo/odoo/blob/5cf96828652c2388808b3e49ae67e188c401ec63/addons/project/models/project_task.py#L2051-L2071

sentry-6982269693

Forward-Port-Of: odoo/odoo#235184

```
File "/tmp/tmpm_3a__2e/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 340, in migrate
    generate_or_refresh_all_returns(company)
  File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 228, in _generate_or_refresh_all_returns
    self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 24, in _generate_all_returns
    super()._generate_all_returns(country_code, main_company, tax_unit=tax_unit)
  File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 281, in _generate_all_returns
    report_type._try_create_returns_for_fiscal_year(main_company, tax_unit=tax_unit)
  File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 353, in _try_create_returns_for_fiscal_year
    period_date_from, period_date_to = self._get_period_boundaries(main_company, date_pointer)
  File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 530, in _get_period_boundaries
    start_day, start_month = self._get_start_date_elements(company_id)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 16, in _get_start_date_elements
    fiscal_year_date = date(2025, int(main_company.fiscalyear_last_month), main_company.fiscalyear_last_day)
ValueError: day is out of range for month
```
```
(Pdb) main_company
res.company(3,)
(Pdb) main_company.fiscalyear_last_month
'2'
(Pdb) main_company.fiscalyear_last_day
29
(Pdb) date_from
datetime.date(2025, 3, 1)
```
- During the migration process the system calls [_generate_or_refresh_all_returns](https://github.com/odoo/upgrade/blob/e20a9e2edec4441b2c7aa5858db2a53fb2e9b215/migrations/account_reports/saas~18.3.1.0/end-account-returns.py#L340) which internally uses [_get_start_date_elements](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L14) to compute the fiscal year start date.
- The customer has configured fiscalyear_last_month = February and fiscalyear_last_day = 29 Because of this configuration, the method attempts to construct 29th February 2025, which is invalid since 2025 is not a leap year. The issue occurs because the method uses a hardcoded year [(2025)](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L16) instead of determining the year dynamically.
- I reviewed implementations in other localizations and found that this logic has [1](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_uk_reports/models/account_return.py#L33), [2](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_nz_reports/models/account_return.py#L8) already been corrected there to compute the appropriate start date dynamically.
- I’ve updated this localization to follow the improved implementation used in other countries, so the start-date calculation now works correctly in all cases, including leap years and any fiscal year settings the customer may configure.

opw-5249243

Forward-Port-Of: odoo/enterprise#99353

When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items.

The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number
https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206

Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them.

This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider.

opw-5086823

Forward-Port-Of: odoo/odoo#234481

When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.

Example of recevied webhook:
```
{
  'apiFullVersion': 'v1.1',
  'apiVersion': 'v1',
  ...
  'payment': {
     'status': 'AUTHORIZATION_REQUESTED',
      'statusOutput': {
        'isAuthorized': False,
        'isCancellable': False,
        'isRefundable': False,
        'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
        'statusCode': 51
      }
   },
 'type': 'payment.authorization_requested'
}
```

Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.

But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.

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

Forward-Port-Of: odoo/odoo#235847

This commit contains 2 things:
- an helper to extract any tax_data and move it to another base_line
- the usage of this helper in UBL to turn emptying taxes into additional base_lines

== Add helpers to turn tax_data into new base_lines easily ==

With this helper, you can now exclude any tax from any base line and turn
them into new base lines.

Also, I changed a bit the smooth distribution of rounding because the math.ceil
is sometimes too greedy and make the whole results to be less accurate.

== Make a different behavior between recycling contribution taxes / emptying taxes ==

In UBL, all fixed taxes are treated as allowances/charges.
In this commit, we make a clear distinction between recycling contribution taxes
that are treated as allowances/charges and emptying taxes that are exempted of tax
and are treated as addition invoice lines in the document.

== Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function ==

The aggregator wasn't called when setting the 'target_base_line' at the very first time.

task_id: 5182783

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

Forward-Port-Of: odoo/odoo#235580
Forward-Port-Of: odoo/odoo#234489

When you have a vendor bill with an invoice line linked to a journal item with the display type "non_deductible_product", if you modify the account_id of the invoice line, then the account_id of the linked line should change to have the same value.

How to reproduce?
  1. Create an asset model (Accounting > Configuration > Accounting > Asset Models)
  2. Set the asset_model_id on an account (on the tab "Automation", set "Automate Asset" as "Create in draft" then set the "Asset Model" field with the created asset model
  3. Duplicate the account having the created asset model
  4. Create a vendor bill with an invoice line having:
    - A strictly positive price unit
    - A deductible_amount (Professional %) lower than 100 (this field is hidden by default)
  5. Modify the account_id of the invoice line
  6. Observe the journal items: the line with the non- deductible product should have the same account_id than the invoice line but it's not the case.

task-5156256

Forward-Port-Of: odoo/odoo#232121

Since PR [1], there was an issue with the statusbar field and the way it put overflowing items into dropdowns (cf. adjust function). Have a form view with a statusbar field and enough items s.t. they don't all fit in the screen. The widget implements a logic to put the first and/or last overflowing items into dropdowns (one before the displayed items, one after).

Before this commit, if the user clicked on an item to select it as new value, the state of the widget was incorrect, leading to dropdowns being displayed, but empty (and items being unavailable, as they are hidden, but not displayed in the dropdown).

This was due to a `useEffect` with an incorrect dependency: if two consecutive renderings were done with the `shouldAdjust` status (which is possible since [1] and the introduction of the `forceRecomputeItems` flag), the dependency didn't change and the callback of `useEffect` was not called, leading to items not being processed.

[1] https://github.com/odoo/odoo/pull/230548

opw~5232448

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

Before this commit:
- The `.dat` export adjusted its date based on the selected export type’s periodicity (quarterly or annually) using the report filter's date_to.
- This caused mismatches where the `.dat` file showed a different period than the report data.
- The adjustment only changed the date in header of `.dat` file but did not restrict data accordingly, leading to inconsistencies when exporting reports with different filter and periodicity types.
- Example: If the report filter is set to 'October 2025' month and the export type's periodicity is 'Annual', the `.dat` file would show 12/31/2025 even though the data in `.dat` file only covers 'October 2025'. Similar mismatch occurs for 'month & quarter' and 'annual & quarter' combinations.

After this commit:
- The `.dat` export date now fully depends on the report’s date filter, keeping report data and export date consistent.
- A non blocking warning is added in the `.dat` export wizard when the report period type is different from the export type's periodicity, helping users select the correct period type while still allowing export if intended.

task-5172259

Currently, an error occurs when user removes value from `Based On` field and saving.

Steps to replicate:
- Install `website_sale` with demo and enable pricelists from settings.
- Open pricelists and Open any Pricelist.
- Under the pricelist rules, make sure `Price Type` is selected as Formula.
- Remove value from `Based Price` and click elsewhere.

Error:
`KeyError: False`

Cause:
- As the `base` field was changed the compute was called and `item.base` was passed on as 'False' at line [1] and caused the Keyerror.

Solution:
- The code skips execution when `item.base` is False, as there is no point in making the `item.rule_tip` [2] if we dont have all the values.

[1]: https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/product/models/product_pricelist_item.py#L287

[2]: https://github.com/odoo/odoo/blob/257537584bedc1ab7db1bdc700f89145a3bb6095/addons/product/models/product_pricelist_item.py#L284-L296

sentry-6948941509

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

Versions
--------
- 19.0+

Steps
-----
1. Have a browser open with a side-bar or that isn't full-screen;
2. open website editor on a product page;
3. enable zoom-on-click;
4. replace the main image;
5. save changes;
6. click on the new image to zoom in;
7. download the image.

Issue
-----
The image is too small & low quality.

Cause
-----
The `this.dependencies.media_website.replaceMedia(image)` call is meant to be used along with an html editor widget to select size & quality. As we have a custom widget to handle product images, the image that ends up getting uploaded is one that's been optimized for the current viewport size.

Solution
--------
Replace the `replaceMedia` call with custom logic similar to that used for extra media, drawing the image to a `canvas` element, and then saving it as the product's `image_1920` field.

Additionally, enable extra media to get saved as in 1920 size, and remove the hardcoded `0.75` image quality value, as a value this low easily leads to visible compression artifacts.

opw-5088032

This fix a traceback:
- Create a report "A" with Period Comparison set to True
- Create a report "B" with Period Comparison set to False
- Create a composite report with report "B" inside.
- Use the variant filter to switch from report "A" to the composite report

This happens because of a UI refresh in `loadReportOptions` trigged by:
- delete this.reportOptionsMap[cacheKey];
- delete this.loadingCallNumberByCacheKey[cacheKey];

When refreshing the UI, it will start with the cachedOption set to the value of the displayed report (report "A"), and is able to pass the condition inside `filters.xml`: `<t t-if="controller.filters.show_period_comparison">`.

While this is happening, the loading of the new report "composite" reaches `this.cachedFilterOptions = options;`. However, the UI refresh is still ongoing, and when it reaches `<t t-if="controller.cachedFilterOptions.comparison.string">` in `filter_comparaison.xml`. If the new report doesn't have the comparaison filter enabled, cachedFilterOptions.comparison will be undefined triggering the traceback.

This is fixed by marking the objects, that would trigger this useless refresh, as raw preventing them from triggering a refresh.

This only happened on composite reports since the cacheKey used to load them is different from the one received by the call to get_options due to the sections.

task-5085985

#### Steps to Reproduce
- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
- Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.
- Update controller logic to prevent public users from accessing an offer link if the offer's employee has a linked user.

task-5051394

Steps to reproduce:
- Install 'sale_stock_margin' module
- Create SO > Create product with category -> 'Costing Method' : 'FIFO'
- 'Confirm' SO > Change product 'Quantity' to zero

Traceback:
ZeroDivisionError: float division by zero

At [1], this error occurs because both 'product_uom_qty' and 'qty_delivered'
are '0', resulting in a denominator of zero, which is not allowed.

[1]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/addons/sale_stock_margin/models/sale_order_line.py#L23

Issue also occurs when 'product_uom_qty' = 0 and 'qty_delivery' < 0
since `qty_from_delivery + qty_from_std_price` = 0 in this case.

Expected result:
- If both `product_uom_qty` = `qty_delivered` = 0 => fallback on
  standard_price (default behavior when only `sale_margin` installed)
- If `qty_delivery <= 0` => fallback on `standard_price` to avoid
  inconsistent values for return moves, i.e. value would vary depending
  on whether or not the return is linked to a delivery (i.e.
  `price_unit_from_delivery`) whereas a return not linked to a delivery
  will default to `standard_price`

sentry-6978885438

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

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99592
Forward-Port-Of: odoo/enterprise#99232

Scenario:

- create a page with url "가" (\N{HANGUL SYLLABLE GA})

then in safari: copy the url to open it in a new tab => a 404 error is shown
in all browser: go to /가 writing it manually => a 404 error is shown

Cause:

We decompose the unicode combination to remove diacritics, but never
recompose them, so we save the slug
\N{HANGUL CHOSEONG KIYEOK}\N{HANGUL JUNGSEONG A} (NFD normalization)
instead of \N{HANGUL SYLLABLE GA} (NFC normalization). Those appear
exactly the same, but when typing you would usually use the NFC one.

Comparing other software, they usually convert NFD to NFC but not the
other way.

When you use the address bar in safari, the URL is normalized with NFC
so you can't type or copy paste a NFKD path to get to it (and can only
get to it by link).

But the issue still exists for other browser where you will usually
manually type NFC and not NFKD.

This is not reproduced, but this could also have effect with search motor
that would normalize link content.

Fix:

When creating slug, normalize to NFC after the removal of diacritics.

opw-5184532

__pr note:__

the original ticket also reported about removal of diacritical mark in Vietnamese and Japanese, but this seems a more of a feature for master change since we have had "éléphant" becomes "elephant" since forever.

other services that allow unicode in path (such as wordpress, wix) seems to just keep the diacritics and normalize to NFC even if the input was in NFD.

for NFD / NFC explanation: https://docs.python.org/3/library/unicodedata.html#unicodedata.normalize

Forward-Port-Of: odoo/odoo#234416