The timesheet and planning shift form views now avoid showing the same approval-related actions in both the header and the actions menu. This reduces duplicate options and makes the form screens clearer for users without changing the underlying workflow.

Before this commit, the `Validate` and `Reset to Draft` buttons are displayed in the header of the timesheet form view but also in the `CogMenu` (actions dropdown), which is a bit redundant since the buttons in the header of the form view are sufficient.

This commit removes the `Validate` and `Reset to Draft` buttons inside the Cog menu when we are in the form view.

task-4279748

Updates several Odoo apps to follow the latest guidelines for scheduled background tasks. This should make recurring maintenance jobs more consistent and reliable without changing day-to-day user workflows.

Several Odoo apps were updated to follow the latest guidelines for scheduled background tasks. This helps make routine automated work more consistent and easier to maintain, with limited direct impact on day-to-day users.

This update adjusts scheduled accounting and localization tasks to follow Odoo’s new background job guidelines. It should make recurring processes such as bank synchronization, follow-ups, currency rates, and tax/reporting exports more consistent and easier to maintain, with limited direct impact on day-to-day users.

This update adjusts the appointment scheduling area to help automated checks run more reliably. It reduces the risk of unstable test results, supporting smoother maintenance without changing day-to-day business workflows.

The subscription expiration background process has been cleaned up to make it easier to maintain and more reliable. This reduces internal complexity around subscription lifecycle handling without introducing a major visible change for users.

Updates scheduled background tasks for Marketing Automation, Social, Push Notifications, and WhatsApp to follow the latest operational guidelines. This should help these automated processes run more consistently and predictably without changing day-to-day user workflows.

This update aligns several HR, payroll, appraisal, and salary contract background processes with newer scheduling guidelines. It should make recurring administrative tasks more consistent and reliable across core HR features and country-specific payroll flows.

This update aligns scheduled background jobs for SEPA direct debit, Amazon sales, and eBay sales with the latest Odoo guidelines. It helps improve consistency and reliability of automated sales and payment processing tasks without changing day-to-day user workflows.

main PR: odoo/odoo#151628
task-id: 3687442

Subscription sales orders now keep more details about upselling opportunities over time. This helps sales teams retain a clearer history of what was delivered or invoiced, making it easier to identify and follow up on growth opportunities.

…on_stock

As the SO for subscription are updated every recurrence, it's hard to keep track of possible upselling opportunities.

This change update the sale upselling opportunity for subscription to save more information regarding the opportunity and don't erase old activities to keep a better record of what has been deliverd/invoiced.

task-id : 3323129

This update aligns subscription and document signing background jobs with newer scheduling guidelines. It should make recurring subscription and signing processes more consistent and easier to maintain, with limited direct impact on day-to-day users.

https://github.com/odoo/odoo/pull/151732

Odoo Sign now lets users avoid creating extra activities and emails for signature requests they initiate. This helps teams such as payroll reduce notification overload when they already know about the documents they sent.

When you work with sign, for a sign request,
you'll get many emails and activities for a signature request that you created. For a payroll team it can be quite heavy.

In addition, according to the way you work, you maybe don't want to be spammed with activities and/or emails for something that you're already know because you asked/created it.

task-id 2984651

This fixes an issue where customers could run into problems when making an early payment on a subscription with a zero amount. It helps ensure the subscription payment flow works correctly even when no money is due.

Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...) This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (see community PR) and displaying an error in the side panel of the pivot (this commit) Task: 4280402 Forward-Port-Of: odoo/enterprise#72576

Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...)

This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (see community PR) and displaying an error in the side panel of the pivot (this commit)

Task: 4280402

Forward-Port-Of: odoo/enterprise#72576

this commit prevent the auto installation of the french payroll because it's not up to date and currently maintained task-4283506 Forward-Port-Of: odoo/enterprise#72980

this commit prevent the auto installation of
the french payroll because it's not up to date
and currently maintained

task-4283506

Forward-Port-Of: odoo/enterprise#72980

### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access th

### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create a vendor bill with this partner using the tax "Exento"
- Go to Reports -> Tax report -> DIOT.txt

### Cause:
For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access the value "third_party_code" in a dictionary but the key is not there so an error is raised.

This occurs because the tax "Exento" is "on_invoice" so there are no cash basis entry created. But in the custom query to retrieve the information of the partners it is specified the journal_id must be part of the cash basis journals. So no lines with "on_invoice" taxes were selected.

### Solution:
Remove the journal restriction.

opw-4312155

Forward-Port-Of: odoo/enterprise#74585
Forward-Port-Of: odoo/enterprise#74105

Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74407

Steps to reproduce
==================

- Go to planning
- Open studio
- Change the default scale to Month (expanded)
- Close studio
- Switch to Schedule > By Role

=> Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]'

Cause of the issue
==================

The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales.

opw-4175183

Forward-Port-Of: odoo/enterprise#74407

Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past

Purpose
=======
Fix the calendar slots selection display when sharing appointment availabilities.

Specification
=============
The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm).

Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past cells when sharing availabilities.

Additionally, for today, a div with a computed height was added to gray out cells before the current time. This div is now pushing the non-business hours divs which makes them overflow the day display.
Fixing that by changing today's past hours div to position absolute.

related commit: odoo/odoo@09ddd9f46c0d7528cb0138af283f6ec4f388a445

Task-4337795

Forward-Port-Of: odoo/enterprise#74349

This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the border-color hex will not adapt it if we are in dark mode). Same thing goes for some color mix that were using `$o-white` thus pure black in dark mode, while it should have used `$o-view-background-color` which is already dark mode proof. Since we were tweaking some values here and there, this com

This PR fixes some minor color scheme issue within Documents.
Prior to this PR, some elements where using raw values instead of BS
one, which led to some dark mode issues (e.g hardcoding the border-color
hex will not adapt it if we are in dark mode).

Same thing goes for some color mix that were using `$o-white` thus pure
black in dark mode, while it should have used `$o-view-background-color`
which is already dark mode proof.

Since we were tweaking some values here and there, this commit adapts
some part of the code by rationalizing the value, either by using BS
variables, CSS one to ease the maintainability of the code as well as
avoiding `!important` statements.

| 18.0 | This PR |
|--------|--------|
| <img width="310" alt="image" src="https://github.com/user-attachments/assets/16bcf240-84aa-4788-8527-7103a80deb40"> | <img width="308" alt="image" src="https://github.com/user-attachments/assets/476b6fd3-ab4d-4b1e-bf51-1ef50151f333"> |
| ![image](https://github.com/user-attachments/assets/b8e6baf9-8cff-4b8a-94cb-30aa753f5191) | ![image](https://github.com/user-attachments/assets/bc207722-6408-416b-a094-85bc2425c4ac) | 

task-4357165

Forward-Port-Of: odoo/enterprise#74464

When the customer clicks on the validate button in delivery with Sendcloud carrier, a traceback will appear. Steps to reproduce the error: - Enable Sendcloud Connecter - Go to Inventory > Configuration > Delivery Methods > Create new Method > Provider: SendCloud > Max Weight: 2 kg - Create a new product A > Type: Goods > Weight: 10 kg - Create a new Delivery > add Product A > Carrier: SendCloud > Validate Traceback: ``` File "home/odoo/src/enterprise/18.0/delivery_sendcloud/mode

When the customer clicks on the validate button in delivery with Sendcloud carrier,
a traceback will appear.

Steps to reproduce the error:
- Enable Sendcloud Connecter
- Go to Inventory > Configuration > Delivery Methods > Create new Method >
  Provider: SendCloud > Max Weight: 2 kg
- Create a new product A > Type: Goods > Weight: 10 kg
- Create a new Delivery > add Product A > Carrier: SendCloud > Validate

Traceback:
```
 File "home/odoo/src/enterprise/18.0/delivery_sendcloud/models/sendcloud_service.py", line 389, in _prepare_parcel
    product_moves = format_list(self.env, overweight_products.mapped('name'))
AttributeError: 'SendCloud' object has no attribute 'env'
```

https://github.com/odoo/enterprise/blob/5dd7022e079bbb45492356a66a60c98a249cec8a/delivery_sendcloud/models/sendcloud_service.py#L389
Here, ``self`` is used instead of ``picking``,
So, It will lead to the above traceback.

sentry-6086972478

Forward-Port-Of: odoo/enterprise#74474

Backport of https://github.com/odoo/enterprise/pull/69565 Forward-Port-Of: odoo/enterprise#73994

Backport of https://github.com/odoo/enterprise/pull/69565

Forward-Port-Of: odoo/enterprise#73994

Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74619 Forward-Port-Of: odoo/enterprise#74552

Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint.

To fix it, disable the constraint for service invoices.

opw-4354637

Forward-Port-Of: odoo/enterprise#74619
Forward-Port-Of: odoo/enterprise#74552