This update makes point-of-sale related test setup more consistent by ensuring test users have a timezone configured. It helps prevent false test failures in no-demo environments and speeds up some internal test user creation, improving release reliability without changing customer-facing behavior.

Ensuring TZ allows to avoid issues in no-demo mode, notably when a timezone is required in sub records, like appointment types.

Runbot-60487

This update fixes a small typo in the messaging test mock data and adds a missing default contact model needed by WhatsApp-related tests. The change helps keep automated testing reliable without affecting day-to-day user workflows.

**Current behavior before PR:**

- There is a typo mistake in `add_members` of Discuss Channel mock model.
- WhatsApp tests needs an `ir.model` record. Which is not available.

**Desired behavior after PR is merged:**

- Fixed the typo mistake.
- Added a default `res.partner` `ir.model` data.

**task**-[3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form)

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

This update sets a consistent time zone for point-of-sale restaurant appointment test users so automated checks behave reliably when demo data is not loaded. It helps prevent false test failures related to appointment scheduling details, supporting smoother validation before releases.

Ensuring TZ allows to avoid issues in no-demo mode, notably when a timezone is required in sub records, like appointment types.

Runbot-60487

Customer references on subscription portal pages are now displayed correctly regardless of the visitor's language. This prevents important subscription identification details from disappearing when customers view the portal in languages other than English.

We should not rely on the `type_name` field (which is a translated) to determine if an order is a confirmed subscription.

To reproduce:
- Active a second language (for. ex French) and enable it as well for the current website
- Create a subscription, set a customer reference to 'CUST-REF' then confirm it
- Click on "Preview"

=> In English, the 'CUST-REF' is visible in the subscription header, in
  other languages it was not visible.

The Approvals app test suite was moved to a newer testing framework. This helps keep internal quality checks current and easier to maintain, with no expected change for end users.

part of task-3818666

__Current behavior before commit:__ If the `badge_image` field of the event isn't set, the badge div's style defaults to `background-image: url();`. When `wkhtmltopdf` interprets this, it attempts to fetch the background image from the website's base URL. Consequently, each time the badge PDF is generated, `wkhtmltopdf` accesses the website's homepage, inadvertently altering the `website_visitor` table. If the badge PDF creation is triggered by a request from the website, it will lead to a dead

__Current behavior before commit:__
If the `badge_image` field of the event isn't set, the badge div's style defaults to `background-image: url();`. When `wkhtmltopdf` interprets this, it attempts to fetch the background image from the website's base URL. Consequently, each time the badge PDF is generated, `wkhtmltopdf` accesses the website's homepage, inadvertently altering the `website_visitor` table. If the badge PDF creation is triggered by a request from the website, it will lead to a deadlock due to simultaneous transactions on the same `website_visitor` row.

__Description of the fix:__
Do not write the `background-image` instruction at all when `badge_image` is not set.

__Steps to reproduce the issue on runbot:__
- Install `website_event`
- Go to Email Templates > **Event: Registration Confirmation** > Settings
- Put `Badge` in **Dynamic Reports**
- Create a new Event and register to it on its website page

-> The registration loads forever and it's impossible to go on any other page on the website

opw-3884132

Forward-Port-Of: odoo/odoo#164566

Steps ----- 1. Have inventory installed. 2. Have a product belonging to a company with a branch. 3. Create a SO with this branch and add the product to it. 4. Confirm the SO. ** Invalid Operation : incompatible companies on records ** Issue ----- While it is possible to add a product from a parent company to a SO, we get an error when confirming the SO and creating the move because of https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/sto

Steps
-----
1. Have inventory installed.
2. Have a product belonging to a company with a branch.
3. Create a SO with this branch and add the product to it.
4. Confirm the SO.
** Invalid Operation : incompatible companies on records **

Issue
-----
While it is possible to add a product from a parent company to
a SO, we get an error when confirming the SO and creating the move because
of
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move.py#L1358
As the product_id field of stock.move has check_company=True, we have
an inconsistency because we are using the default domain of
_check_company_domain which is just the company itself.
https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L3999-L4007

Fix
-----
We provide a new _check_company_domain to product.product.
https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed made changes to allow products
to be used by branches, in particular this security rule:
https://github.com/odoo/odoo/blob/5a801bc60209713a3ba5313debb4daa05c4e2405/addons/product/security/product_security.xml#L34-L38

**opw-3815736**

Forward-Port-Of: odoo/odoo#160899

Steps to reproduce: - Install purchase, project and accounting - Setup an analytic distribution for the projec - Add a new item from the catalogue Issues: The analytic distribution is not added automatically as it would when adding an item without using the catalogue. Solution: The compute that add the analytic distribution requires the `project_id` to be in the context. https://github.com/odoo/odoo/blob/ed0bf10ad89ee78acc65f4e7be70c7ffb2a864bb/addons/project_purchase/models/purc

Steps to reproduce:
- Install purchase, project and accounting
- Setup an analytic distribution for the projec
- Add a new item from the catalogue

Issues:
The analytic distribution is not added automatically as it would when
adding an item without using the catalogue.

Solution:
The compute that add the analytic distribution requires the `project_id`
to be in the context.

https://github.com/odoo/odoo/blob/ed0bf10ad89ee78acc65f4e7be70c7ffb2a864bb/addons/project_purchase/models/purchase_order_line.py#L13

However if we go to the catalogue and add the items our context will be
flushed, but this flush will be done with the old env.
By passing the context and using `_recompute_recordset` we are
forcing the compute with the env that has the correct context.

As a side note `_recompute_recordset` is used instead of
`flush_recordset` in order to prevent write operations that will be done
later on.

opw-3794948

Forward-Port-Of: odoo/odoo#165135
Forward-Port-Of: odoo/odoo#158924

In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore and not really being the same ressource anymore. This is a bit weird conceptually. Indeed, the generic page is not shadowed by the specific one anymore. This is an issue because when going on the generic page and editing it, the save will actually "bug": it will not write on the generic view that

In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore and not really being the same ressource anymore. This is a bit weird conceptually.
Indeed, the generic page is not shadowed by the specific one anymore.

This is an issue because when going on the generic page and editing it, the save will actually "bug": it will not write on the generic view that you edited but the save will instead be "redirected" (through the COW mechanism) to the specific view.
The editor will look like it did not save your change, while in fact it actually erased, behind the scene, the specific page content and replaced it by the one you tried to save on the generic page. You really just lost your specific page content without knowing it.

This is a corner case of the COW mechanism and the holy grail rule of multi website (editing a website should only impact itself and not other websites): we serve both the generic content and its specific content on the website, which should never be possible except for this particular case of a view being linked to a page and the specific view's page having its URL changed.

Note that an apparently good solution would be to adapt the view key to reflect its new page URL (as when you create a new page), but it's not possible. We don't do that for a simple reason: the page view's key could be xpath'd. And it is even the case for the contactus page. Even if it is not a very legit flow to xpath a page view, because it makes (most of the time) that page not possible to edit, we have to support it.

Also note that a generic page is not something supposed to exist, even if we support it (and use it for /contactus), it's best to avoid it:
1. You can't do that through the UI unless going into debug mode
2. It does not make a lot of sense to share a whole page content on multiple websites, as it would duplicated content (bad for SEO).

Steps to reproduce:
- Go to /contactus and enter edit mode
- Change something like add "WEBSITE1" somewhere in the page
- Open the page properties and change the url from /contactus to /contactuswebsite1
- Go to /contactus, which will still be available and now show the generic page
- You will not see the "WEBSITE1" you added, which is what is expected as this is the generic page, the "WEBSITE1" is on the /contactuswebsite1 page
- Enter edit mode and add something, like "GENERIC", save
- The page will reload (as you saved) but your "GENERIC" will disappear, looking like it did not save your change
- Now go to /contactuswebsite1, you will see that the "WEBSITE1" word is gone, and the "GENERIC" word is there

On top of the following OPWs, the bug was also reported internally on discord.
opw-3760257
opw-3473923
task-3476840

Forward-Port-Of: odoo/odoo#163038
Forward-Port-Of: odoo/odoo#159297

Before this commit, when trying to highlight a message containing a single quote you get a traceback. To reproduce: - post a message with body "can't" - search for "can" - search for "can't" This happens because the XPath expression with unescaped single quotes becomes invalid. This commit fixes the issue by escaping the single quotes using the XPath concat() function. --- Before this commit, trying to search for a message containing a round bracket would produce a traceback. -

Before this commit, when trying to highlight a message containing a single quote you get a traceback.
To reproduce:
- post a message with body "can't"
- search for "can"
- search for "can't"

This happens because the XPath expression with unescaped single quotes becomes invalid.

This commit fixes the issue by escaping the single quotes using the XPath concat() function.

---

Before this commit, trying to search for a message containing a round bracket would produce a traceback.
- search for the string "("

This happens because the search term is not being escaped for the regexp.

This commit fixes the issue by escaping the search term. Same is being done on the mock server. Added tests.

Forward-Port-Of: odoo/odoo#164991
Forward-Port-Of: odoo/odoo#164320

### Before this commit: The fileViewer toolbar buttons displayed incorrect colors for portal users. ### Reason for this behaviour The mail module's public assets loaded all components and their SCSS files. However, the file viewer had a separate SCSS file for dark mode button colors, which was unnecessary for portal users. Removing it would help fix the bug. ### After this commit: FileViewer toolbar button colors now display correctly for portal users. **task-3872205** For

### Before this commit:
The fileViewer toolbar buttons displayed incorrect colors for 
portal users.

### Reason for this behaviour
The mail module's public assets loaded all components and 
their SCSS files. However, the file viewer had a separate SCSS 
file for dark mode button colors, which was unnecessary for 
portal users. Removing it would help fix the bug.

### After this commit:
FileViewer toolbar button colors now display correctly for portal 
users.

**task-3872205**

Forward-Port-Of: odoo/odoo#163933

**Current behavior before PR:** when opening livechat session history from the session history listview in mobile it results in error because the function "fetchChannelInfo" uses to fetch the channel info was removed in this Commit [ [1](https://github.com/odoo/odoo/commit/18384bb519d95e937ea4cfdd660ac08ba89214c0) ] **Desired behavior after PR is merged:** Resolved issue by replacing error causing function with alternative "getOrFetch" function. Task-3889899 --- I confirm I have

**Current behavior before PR:**

when opening livechat session history from the session history
listview in mobile it results in error because the function "fetchChannelInfo" uses 
to fetch the channel info was removed in this Commit [ [1](https://github.com/odoo/odoo/commit/18384bb519d95e937ea4cfdd660ac08ba89214c0) ]

**Desired behavior after PR is merged:**

Resolved issue by replacing error causing function with alternative "getOrFetch" function.

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

Forward-Port-Of: odoo/odoo#163303

Description of the issue/feature this PR addresses: It is not necessary to put the UY- at the beginning because they only appear if the country is Uruguay Task: 88 Task in adhoc: 6022 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 Forward-Port-Of: odoo/odoo#164352

Description of the issue/feature this PR addresses:
It is not necessary to put the UY- at the beginning because they only appear if the country is Uruguay
Task: 88
Task in adhoc: 6022

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

Forward-Port-Of: odoo/odoo#164352

Current behavior: --- When applying for a job offer, if the partner already exists, it will create a new one anyway. Steps to reproduce: --- 1. install website_hr_recruitment,contacts 2. Go to contacts => only one admin partner 3. Go to Recruitment, select a job offer 4. Click on Job Page, Apply Now! 5. The form should be prefilled with admin info 6. Add missing information (LinkedIn and resume) 7. Click on I'm feeling lucky 8. Go to contacts => two admin partners Cause of the i

Current behavior:
---
When applying for a job offer, if the partner already exists, it will create a new one anyway.

Steps to reproduce:
---
1. install website_hr_recruitment,contacts
2. Go to contacts => only one admin partner
3. Go to Recruitment, select a job offer
4. Click on Job Page, Apply Now!
5. The form should be prefilled with admin info
6. Add missing information (LinkedIn and resume)
7. Click on I'm feeling lucky
8. Go to contacts => two admin partners

Cause of the issue:
---
Introduced by: https://github.com/odoo/odoo/commit/7774822c0ba9edf979cdc741a6c465a8e84e4da6 
When creating an applicant, partner_id is False

opw-3837388

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

Forward-Port-Of: odoo/odoo#161732

Current behavior: When specifying a pricelist on a loyalty program, it would not work anymore. Point are not being added anymore Steps to reproduce: - Create a loyalty program that gives 1 point for 0.1€ - Open any PoS - Select a partner and add some products - The loyalty points are not added Note: This was happening because `pricelist_ids` do not contain ids but pricelist object that contains the id and other informations. opw-3818483 --- I confirm I have signed the CLA and re

Current behavior:
When specifying a pricelist on a loyalty program, it would not work anymore. Point are not being added anymore

Steps to reproduce:
- Create a loyalty program that gives 1 point for 0.1€
- Open any PoS
- Select a partner and add some products
- The loyalty points are not added

Note:
This was happening because `pricelist_ids` do not contain ids but pricelist object that contains the id and other informations.

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

Forward-Port-Of: odoo/odoo#163579

Versions: ------------ 16.0 Steps to reproduce: ------------------- 1)Update the email field of users with gmail id for admin and demo 2) Connect odoo with google calendar 3) Create a recurring event with admin as Organizer, demo as attendee and recurrence as "Daily" with "1" repeatation. 4) Then edit the event by changing the repeatation as "2" and save it in "This and following event" 5) Check the event duplication Issue: ------- Recurring events in the calendar are being duplic

Versions:
------------
16.0

Steps to reproduce:
-------------------
1)Update the email field of users with gmail id for admin and demo 2) Connect odoo with google calendar
3) Create a recurring event with admin as Organizer, demo as attendee and recurrence as "Daily" with "1" repeatation.
4) Then edit the event by changing the repeatation as "2" and save it in "This and following event"
5) Check the event duplication

Issue:
-------
Recurring events in the calendar are being duplicated.

Cause:
------
The `_apply_recurrence_values` method is being called twice, resulting in duplicate events.

Solution:
---------
Added a condition to prevent the method from being called multiple times.

task-3786429

Forward-Port-Of: odoo/odoo#160062

Currently, when we use eCommerce with automatic invoicing enabled, and we have the Peppol format enabled in the invoicing settings, there is an issue when coupons or discount codes are applied. These discounts create a sale order line (and afterwards a move line) with a negative unit price. Since UBL BIS3 does not allow negative unit prices, the automatic generation of the e-invoice is not executed and the customer receives a "proforma invoice" PDF instead (which has no official value). A mes

Currently, when we use eCommerce with automatic invoicing enabled, and we have the Peppol format enabled in the invoicing settings, there is an issue when coupons or discount codes are applied.

These discounts create a sale order line (and afterwards a move line) with a negative unit price. Since UBL BIS3 does not allow negative unit prices, the automatic generation of the e-invoice is not executed and the customer receives a "proforma invoice" PDF instead (which has no official value). A message is logged in the chatter, but the user has no notification or anything.

We can do better, and instead invert both the unit price and quantity fields (since UBL BIS3 does allow negative quantities), to have the same result when generating the e-invoice.

task-3916181

Forward-Port-Of: odoo/odoo#164810
Forward-Port-Of: odoo/odoo#164735

[IMP] account_online_synchronization: populate swift/bic in journals Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals Reason: Improve the user-experience Task-3891695 odoofin-pr: https://github.com/odoo/odoofin/pull/273 Forward-Port-Of: odoo/enterprise#61639

[IMP] account_online_synchronization: populate swift/bic in journals

Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals

Reason: Improve the user-experience

Task-3891695

odoofin-pr: https://github.com/odoo/odoofin/pull/273

Forward-Port-Of: odoo/enterprise#61639

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts. We'll make it required in master. Forward-Port-Of: odoo/enterprise#60847

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts.

We'll make it required in master.

Forward-Port-Of: odoo/enterprise#60847

Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong. In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop. task-3869482 Forward-Port-Of: odoo/enterprise#62327 Forward-Port-Of: odoo/enterprise#61302

Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong.

In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop.

task-3869482

Forward-Port-Of: odoo/enterprise#62327
Forward-Port-Of: odoo/enterprise#61302

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank. UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/pay

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank.

UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/payments-and-reporting/insidebusiness-payments/domestic-uk-file-format-description-february-2024.pdf that this identifier should be 999999 + 4 blanks or SUN + 4 blanks, so we make the choice to use 999999 if we have no SUN, for HSBC.

We don't want to make the SUN field optional for everyone just because of that one use case. Instead, we ask people to write 'HSBC' as their SUN number in the settings if they don't have any, and this considers the field as blank for the file generation.

(HSBC's doc can be found on the related ticket)
opw-3863262

Forward-Port-Of: odoo/enterprise#62323
Forward-Port-Of: odoo/enterprise#62111

To reproduce: ============= - Create a 24-hour calendar representing a company without breaks. - Create an employee who will be working a night shift 21:30 to 6:00 - Create an open shift from 21:30 to 6:00. - as the company doesn't have breaks the shift will have 8 hours and 30 minutes of allocated hours. Set the allocated hours to 8 hours - click auto-plan -> the employee is assigned to the shift but the allocated hours are changed to 7 hours and 32 minutes. Problem: ======== -

To reproduce:
=============
- Create a 24-hour calendar representing a company without breaks.
- Create an employee who will be working a night shift 21:30 to 6:00
- Create an open shift from 21:30 to 6:00.
- as the company doesn't have breaks the shift will have 8 hours and 30 minutes of allocated hours. Set the allocated hours to 8 hours
- click auto-plan -> the employee is assigned to the shift but the allocated hours are changed
    to 7 hours and 32 minutes.

Problem:
========
- when setting the allocated hours to 8 hours, the allocated percentage changed to 94%.
- after auto-planning, and setting the resource to the shift, the allocated hours are recomputed based on the allocated percentage and the working hours of the resource which is 8 * 0.94 = 7.52 hours.

Solution:
=========
after finding the resource to assign to the shift, we should recomputed the allocated percentage based on the working calendar of the resource and the allocated hours set on the shift.

opw-3874283

Forward-Port-Of: odoo/enterprise#62264

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one. This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it. task-id: none Forward-Port-Of: odoo/enterprise#62227 Forward-Port-Of: odoo/enterprise#60822

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one.

This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it.

task-id: none

Forward-Port-Of: odoo/enterprise#62227
Forward-Port-Of: odoo/enterprise#60822

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered. Steps to reproduce: ------------------- * Go to the **Field Service** App * Switch to the calendar view * Select "Tomorrow" (x+1) * For the new task, set the `Planned Date` as follows: * Start date : The day after tomorrow at 3PM (x+2 3PM) * End date: Three days after the start at 4PM (x+5 4PM) * Fill anything for the other required fields > *

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered.

Steps to reproduce:
-------------------
* Go to the **Field Service** App
* Switch to the calendar view
* Select "Tomorrow" (x+1)
* For the new task, set the `Planned Date` as follows:
  * Start date : The day after tomorrow at 3PM (x+2 3PM)
  * End date: Three days after the start at 4PM (x+5 4PM)
* Fill anything for the other required fields > **Save & Close**
* Switch to the kanban view and select the task created
> Observation: the start date of `Planned Date` is set at Tomorrow 7AM instead of the day after at 3PM

Why the fix:
------------
This behavior was introduced after this commit: https://github.com/odoo/enterprise/commit/39b9362d0469d71b59d47e9d66d5e73b9a46520b.

This commit added an inverse method to the field `planned_date_start` to enable drag and droping tasks in the calendar view. And `planned_date_start` is a field that exists purely for calendar displaying of tasks.

https://github.com/odoo/enterprise/blob/c8c4a52b508621b45239332273832de26a085931/project_enterprise/models/project_task.py#L299-L305

When creating a task in the calendar view, the context contains `default_planned_date_start` and its value depends on the first day you selected in the calendar. At task creation, `default_planned_date_start` triggers a write in `planned_date_start` which triggers its inverse method.

This removes the `default_planned_date_start` from the context which won't trigger the inverse method. We don't have to worry about the line `default_planned_date_begin: default_planned_date_start,` as if we have selected a start date in the form, it will be present inside `vals_list` in the create function and will use that value instead of the one in the context.

opw-3850455

Forward-Port-Of: odoo/enterprise#62232
Forward-Port-Of: odoo/enterprise#61351

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed. opw-3905455 Forward-Port-Of: odoo/enterprise#62185

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed.

opw-3905455

Forward-Port-Of: odoo/enterprise#62185

Before this PR, the sign_request record was browsed but we did not checked if the record was correct. Before this PR, when the sign_document_from_mail controller was called without timestamp parameter, it would redirect to the sign.sign_request_expired template because current_request_item._validate_expiry(post.get('timestamp'), post.get('exp')) would return False. For human triggered interaction, it is not an issue. Some customer complained of massive email sent. One of the signer

Before this PR, the sign_request record was browsed but we did not checked if the record was correct.

Before this PR, when the sign_document_from_mail controller was
called without timestamp parameter, it would redirect to the
sign.sign_request_expired template because
current_request_item._validate_expiry(post.get('timestamp'),
post.get('exp')) would return False.

For human triggered interaction, it is not an issue.

Some customer complained of massive email sent. One of the signer is
probably relying on MS Defender. This is system is known to click on
links in email and cleaning the GET parameters of the URL.

In that case, the bot will get the sign.sign_request_expired which has a
button that allows to resend the sign request. If the bot click on that
button, it will send an email, that will be analyzed by the bot. it will
clean the parameters, get the sign.sign_request_expired template etc
etc.

Forward-Port-Of: odoo/enterprise#61853

Reproducing: 1. Use a folder with one `binary` and one `url`-type documents. 2. Add a tag on the `binary` one. 3. Check the tag in the search panel 4. Share the folder Problem: You are warned about having included a link in the share, but you had not. Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`). Task-3806121 Forward-Port-Of: odoo/enterprise#58650

Reproducing:
1. Use a folder with one `binary` and one `url`-type documents.
2. Add a tag on the `binary` one.
3. Check the tag in the search panel
4. Share the folder

Problem:
You are warned about having included a link in the share, but you had not.

Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`).

Task-3806121

Forward-Port-Of: odoo/enterprise#58650