**Steps to reproduce:**

1. Install the Accounting module.
2. Set a company name longer than 24 characters.
3. Go to Accounting → Reporting → General Ledger.
4. Print the report → in the PDF footer, the company name is truncated.

**Issue:**

- The company name in the General Ledger report footer is cut off if it exceeds 24 characters.

**Cause:**

- The footer uses a static value limited to 24 characters: 

https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860

**Solution:**

- Increased the footer text limit from 24 to 80 characters.

- Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF.

**After Apply Solution**

<img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" />

**Before Without Solution**

<img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" />


opw - 5025972

Forward-Port-Of: odoo/enterprise#94535

Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template.

**Steps to Reproduce:**
1. Configure a WhatsApp Business Account and synchronize the templates.
2. Open any contact and click the **WhatsApp** button next to the phone number.
3. Remove the template and click **Send Message**.

**Error:**
`ValueError - Expected singleton: whatsapp.template()`

**Cause:**
At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error.

**Fix:**
This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template.
In stable versions, raise a validation error if a user attempts to send a message without selecting a template.

[1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319

sentry-6854466874

Forward-Port-Of: odoo/enterprise#93898

## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves

#### Description of the issue/feature this PR addresses:
Editing CZ Company address while having demo data throws Validation Error

#### Current behavior before PR:
When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce:
 - Install l10n_cz with demo data
 - Open CZ Company in form view
 - Change address (e.g. change city Praha -> Brno)
 - Click Save

#### Desired behavior after PR is merged:
The address changes are saved without any error.

#### Solution:
This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin.

Related to: #226152







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

Forward-Port-Of: odoo/odoo#228157
Forward-Port-Of: odoo/odoo#227847

**Issue:**

Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself.

**Cause:**

The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access.
https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76

https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117

**Steps to reproduce:**

1. Create a private project (`privacy_visibility == 'followers'`)
2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access
3. Add Marc Demo as a follower of a task in that private project
4. Have another user log time on that task
5. Log in as Marc Demo

Marc cannot see the other user's timesheets, neither on the task form nor in reporting.

opw-5022877

Forward-Port-Of: odoo/odoo#224025

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > Click on `Edit` > `Drag and drop` form.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - Submit the form, and the error appears in the logs.

`KeyError: 'website_form_signature'`

This error occurs when submitting the "Send Email" form from the
website. When the user chooses the model Outgoing Mails (mail.mail),
the email_to hidden field is not added. This is because email_to is only
added when the recipient email value is changed from the sidebar via
apply [1]. As a result, the email_to hidden field is missing from the form.
And the website_form_signature is added from [2], but due to the
condition at [3], the code at [2] is not executed. When it is accessed
at [4], KeyError is raised.

This commit ensures that when the user selects the action model,
if there is a hidden field email_to, it is added to the form with its
default value.

[1]: https://github.com/odoo/odoo/blob/3b16debc6d6557334082fdf841b20ef0e31fc9d2/addons/website/static/src/builder/plugins/form/form_option_plugin.js#L863

[2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

Related Community PR: https://github.com/odoo/odoo/pull/226598

sentry-6746753251

Steps to Reproduce:
------------------
- Open Helpdesk.
- Go to Configuration → Helpdesk Teams.
- Create a new team.
- Enable the Billing feature and assign a project to this team.
- Set the project’s Company field to Null.
- Create an employee for the current user in another company.
- Ensure the user has employees in both companies.
- Create a new ticket (or open an existing one) in the newly created team.
- Try creating a new timesheet → a Validation Error is raised.

Root Cause:
-----------------
When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs.

**This happens because:**

- The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216
).

- Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. 

Issue Faced:
-------------
In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82),
 which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. 

OPW: 5004092

Forward-Port-Of: odoo/enterprise#95226
Forward-Port-Of: odoo/enterprise#92507

## Issue:
For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule

## Cause:
When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()`
This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end)
These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed:
https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393
We want to use the calendar itself as the calendar resource to get the `work_hours_data`

## Steps to reproduce:
- On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week
- Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6)
- In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values)
- Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off

opw-4881758

Forward-Port-Of: odoo/odoo#225876

## Version
saas-18.4+

## Issue
*Use mobile device or mobile view*
- Configure Paypal as a Payment Provider;
- Go to the shop and buy an article;
- Move to checkout and select PayPal;
- No PayPal button is displayed.

## Cause
In saas-18.4, a refactoring of the checkout layout (7a564237579603bcaef46efd6ffaaaffefb54b11) introduced the `o_mobile_summary` block which results in the full payment form being duplicated in the DOM:
- One copy for desktop:
  - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3524-L3529
- One copy inside `.o_mobile_summary` for mobile:
  - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3557-L3560

This causes the `payment.submit_button` template (and its extension by PayPal) to be injected twice.
As a result, the DOM ends up with two elements sharing the same IDs (`o_paypal_button_container`) which breaks PayPal’s SDK rendering logic.

## Fix
JavaScript logic based on cca908741c7fdd701a4539e5d43c71248b73b14f has been added to detect and rename the duplicated DOM structure:
The PayPal button can be rendered everywhere based on unique IDs.

opw-4942831