Before this commit, when the user clicks on `Make Billable` stat button displayed in the project form view when there is not yet any SO set on that project and directly confirm the SO, a user error is raised because the SO is already confirmed after executing confirm action of that button clicked. The reason is because in that case, the SO is automatically confirmed during the creation of that SO which means the action_confirm could be called 2 times in that use case, one during the save (creation) and another one because the user clicks on `Confirm` button.

This commit makes sure the action_confirm does nothing if the SO is already confirmed and we are in the context in which the user creates the SO via the stat button in project.

Steps to reproduce
------------------
0. install sale_project or sale_timesheet modules
1. Go to Projects > Confirmation > Projects
2. Click on `New` button to create a new project
3. Enable `Billable` feature if it is not already the case by default
4. Add a customer to the project
5. Click on `Make Billable` stat button
6. Add a service product on the SO to create
7. Click on `Confirm` button.

Expected behavior
-----------------

The SO should be created and confirmed without any issues

Current Behavior
----------------

A user error is raised because the SO is already confirmed before executing the action for the button clicked.

task-4781751

Forward-Port-Of: odoo/odoo#209259

**Current behavior before PR:**

Push notifications are shown even when the user is already viewing the same
conversation in the Discuss app or in the ChatWindow. The Service Worker does
not currently check whether the conversation is focused, leading to redundant
and unnecessary notifications.

**Desired behavior after PR is merged:**

The Service Worker now intelligently checks the state of the Discuss and
ChatWindow before displaying push notifications. Notifications are only shown
when the user is not actively focused on the same conversation.
The updated logic ensures:

- Chat bubble minimized and tab focused → Show
- Chat window open, tab focused, but a conversation not focus → Suppress
- Chat window open, tab focused,  the conversation is focused → Suppress

This behavior is achieved by the Service Worker sending a message to the client
window to get the active thread and its focus status before deciding whether to
show a notification. This results in a cleaner user experience by avoiding
redundant alerts when they’re not needed.

task-[4582533](https://www.odoo.com/odoo/my-tasks/4582533)

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

Forward-Port-Of: odoo/odoo#212469
Forward-Port-Of: odoo/odoo#206800

Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted.

Steps to produce:
- Install the `purchase_stock` module.
- Activate `Multi-Step Routes` from Settings.
- Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`.
- Delete the `Buy` route record.
- Create a new product without adding vendors or defining routes.
- Click on the `Replenish` button.
- Observe the error.

`AttributeError: 'NoneType' object has no attribute 'id'`

The issue occurs when attempting to access the `id` of the 'Buy' route `purchase_stock.route_warehouse0_buy` - [1], without verifying if it exists. If this route is missing, `self.env.ref(...)` returns `None` which leads to an `AttributeError`.

This commit resolves the issue by checking whether the `purchase_stock.route_warehouse0_buy` route exists before attempting to access its `id`. This prevents errors when the route is missing.

[1] - https://github.com/odoo/odoo/blob/58f4b01dda6ba2e67c21663399aab1c189f4a312/addons/purchase_stock/wizard/product_replenish.py#L108

Sentry-6275025957

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

Forward-Port-Of: odoo/odoo#196959

Scenario: add a mega menu, in mobile scroll to not be at top of page,
and click to open hamburger menu then click to open mega menu content.

Result: the mega menu is mostly shown thanks to
579160b08c6e73d809be79f561214118f1284532 but a small part at the bottom
is inaccessible.

Reason: the height needs to take into account the margin bottom so it
can be shown fully on the page.

Fix: add a calc to remove the height of the margin-top.

opw-4737577
opw-4737823
opw-4738673

__PR NOTE__: I'm not sure if all browser support of using calc with different units (maybe I'm confusing it with some less calculation), if the solution was not acceptable for that, the only other way I see to solve this, would be to put "position: relative" to the `#top_menu_collapse_mobile .offcanvas-body` element and let the mega menu take the whole space, i.e. something like that:

```diff
diff --git a/addons/website/static/src/scss/website.scss b/addons/website/static/src/scss/website.scss
index 16fdd05e006f..05c9dbbc88cd 100644
--- a/addons/website/static/src/scss/website.scss
+++ b/addons/website/static/src/scss/website.scss
@@ -1629,6 +1629,9 @@ header {
 }

 // Offcanvas mega menu on mobile or in sidebar/hamburger header
+#top_menu_collapse_mobile .offcanvas-body {
+    position: relative;
+}
 .o_mega_menu_is_offcanvas {
     .o_mega_nav, .o_mega_menu {
         @include transition(opacity $offcanvas-transition-duration ease-in-out, visibility $offcanvas-transition-duration ease-in-out);
@@ -1664,7 +1667,6 @@ header {
         inset: 0 0 0 auto !important;
         display: block;
         visibility: hidden;
-        margin-top: $o-mega-menu-nav-height !important;
         border: none;
         max-height: 100vh;
         background-color: o-color('menu-custom') or o-color('menu');
```

Forward-Port-Of: odoo/odoo#207013

**Problem:**
when in a bar/restaurant point of sale
if the tip is added after the payment the
total amount and remaining amount are not correct

**Steps to reproduce:**
- Navigate to Point of Sale/Configuration/Point of Sale
- Create a new point of sale
- In settings, activate the setting "Is a Bar/Restaurant" for this point of sale
- Acivate the setting "Tips" for this point of sale
- make sure the cash payment method is available for this point of sale
- in Point of Sales/Dashboard clik on open regiser for the new point of sale
- Create a new order, select a product, click on payment
- Select cash, on enter an amount over the total value
- Click on Tip, and select Ok (the default amount should be the difference between the total and the cash amount you entered

**Current behavior:**
 The Amount of cash has been increased by the amount of the tip

**Expected behavior:**
The cash amount shouldn't be impacted by the tip

**Cause of the issue:**
When adding the tip inside the addTip method, when settip 
is triggered, the tip is added as a new PosOrderLine inside the order
https://github.com/odoo/odoo/blob/68940a80a64cd81679ad94d488623a471e2c926f/addons/point_of_sale/static/src/app/services/pos_store.js#L636
which modifies total due amount

Then the Pos Payment amount is modified
https://github.com/odoo/odoo/blob/68940a80a64cd81679ad94d488623a471e2c926f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L248
which should not happen when the tip is smaller 
or equal to the remaining amount (if you by something worth 15
,give 20 euros and add a 5 euros tip, the payment amount should
stay 20)

**Fix:**
There is 3 cases.
Case 1: the remaining is negative, then if a tip is added 
it should increase the payment amount
Case 2: the remaining is positive (meaning the client paid 
more than total due) and the tip is lower or equal to the 
remaining, then the payment amount should not increase
Case3: the remaining is positive and the tip is higher than the 
remaining, the payment amount should be increased by the 
difference between tip and remaining

opw-4721864

Forward-Port-Of: odoo/odoo#207030

## Steps to reproduce:
- Create a SO from sales, and don't confirm it
- Enable 'Allow Ship Later' in PoS
- From PoS, settle the SO, with "Ship Later" option

## Observed behavior:
From the inventory app -> Delivery orders, we can see that 2 pickings
for this order have been created, one for the original SO order, and
another one for the PoS order. Both of them are in state 'confirmed',
i.e. "Ready".

## Expected behavior:
The original SO picking should have been cancelled, i.e. in state
'cancel', and only the PoS picking should be "Ready".

## Why that happens:
When settling the SO from PoS, that will create a new order from PoS
with its associated PoS picking. While doing that, we also confirm the
original SO [1], changing its state from 'draft' to 'sale', and that
will create a move and a picknig associated with that SO, both in state
'confirmed'.
So at this point, we're heading toward having 2 pickings, one from the
PoS order and the other from the SO, both in state 'confirmed', which
is undesired! What we want is having the SO's picking in state
'cancel', and the picking from PoS in state 'confirmed' (since we have
settled the order from PoS). To achieve this behavior, we check if the
quantity delivered on the SO (i.e. `so_line.qty_delivered`) compensates
for the qty that should be deliverd, i.e. for `so_line.product_uom_qty`
[2], and if so, we cancel the SO picking ([3], [4]).
However, if the order is "ship later", the `so_line.qty_delivered` will
be 0 at first, and will only get updated when the picking has indeed
being shipped [5], resulting in `new_qty` always being a positive
number, and hence also the `product_uom_qty` on the SO pikcing [6],
meanign that the SO picking will not qualify to be cancelled.

## The fix:
Now, in the computation of `new_qty`, we don't only compare
`so_line.product_uom_qty` with what quantity has indeed been delivered
(i.e. `so_line.qty_delivered`), but also with the quantity that is
expected to be delivered later (i.e. `get_expected_qty_to_ship_later`).

[1]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L74
[2]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L88
[3]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L95
[4]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L103-L104
[5]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/sale_order.py#L57
[6]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L94

opw-4375941
opw-4457592
opw-4490398
opw-4628515
opw-4599490

Forward-Port-Of: odoo/odoo#212460
Forward-Port-Of: odoo/odoo#197031

#PURPOSE:
 - Currently is the user is promoted as admin for accounting and he/she is try
   to generate/regenerate or view the gst report following Error is thrown.
 - Access Error

    ```Uh-oh! Looks like you have stumbled upon some top-secret records.

       Sorry, Marc Demo (id=5) doesn't have 'read' access to:
         - Document (documents.document)```

#STEPS TO REPRODUCE
  1) Install necessary modules for indian accounting localization.
  2) Enable GST E-Filing & Matching Feature from account's configuration.
  3) Go to Settings -> User & Companies -> Users
  4) Click new if no user is there other then administrator else click on
     another user.
  5) Under Access Rights section , inside Accounting select Administrator & Save.
  6) Now log in as new user in another tab.
  7) Go to Accounting -> Reporting under 'India' section click on
     GST Return Period.
  8) Click on generate/regenerate or View option.
  9) The above shown error will be raised.

#SPECIFICATION:
- The issue is with documents access rights
- After promoting user to admin of accounting, the document's folder right is
  not properly assign to user.
- fix this by giving rights of GSTR folder to user if user is in accounting 
  manager group.
  
task-4770583

Forward-Port-Of: odoo/enterprise#86635
Forward-Port-Of: odoo/enterprise#84747