Backport of [this commit].

Babel has a very long standing bug on computing ISO weeks / year-week.

python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not.

python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel.

While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`:

- For ISO locales, delegate to the stdlib which does that fine.
- For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective.

Fix tests embedding incorrect week assignments:

- For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow.
- For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1.

[this commit]: https://github.com/odoo/odoo/commit/75c63315169c0a4c6c92403690c54d606680593b

[^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/

opw-4446254
opw-4448239

Forward-Port-Of: odoo/odoo#202475
Forward-Port-Of: odoo/odoo#199658

Steps to reproduce the issue:

1. Activate the Odoo Mexican Localization Reports module
2. In a Mexican company, create a new Account with 1 as code
3. Go to Trial Balance and download COA SAT (XML)
5. In the General Settings with developer mode active, Download XSD files
6. Go to Trial Balance and download COA SAT (XML) again
7. You get a UserError with an unclear message

Explanation:

The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly.

Fix reasoning:

Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml.

opw-4287338

Forward-Port-Of: odoo/enterprise#81723
Forward-Port-Of: odoo/enterprise#73943

Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount.

To reproduce:

1. Configure Avatax
2. Configure the Discount product to have the "Non-taxable product" Avatax category
2. Create an invoice to Azure Interior
3. Select the Avatax fiscal position
3. Add 1 FURN_6667 with default unit price $295
4. Add 1 Discount with unit price -$295
5. Click "Compute Taxes"

The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items.

`_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line.

This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded.

opw-4493544

## PR note
Alternative to https://github.com/odoo/enterprise/pull/80095.

Forward-Port-Of: odoo/enterprise#81675
Forward-Port-Of: odoo/enterprise#80097

Versions
--------
- 17.0+

Community PR: https://github.com/odoo/odoo/pull/201768

Steps
-----
1. Have a internal user with only Sales: Own Documents access;
2. assign the user to a subscription;
3. as admin, create an invoice for the subscription;
4. assign yoursel as salesman on the invoice;
5. confirm the invoice;
6. log in as the other user;
7. try to create an invoice for the subscription assigned to you.

Issue
-----
Access error.

Cause
-----
Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`.

This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to.

Solution
--------
In `sale`:
- Bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field.

In `sale_subscription`:
- Add a test to prevent regression.

opw-4554639

Forward-Port-Of: odoo/enterprise#81658
Forward-Port-Of: odoo/enterprise#81461

Description of the issue this commit addresses:

A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format.

---

Steps to reproduce:

1. Install l10n_be_coda
2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket.
3. A traceback is raised

---

Desired behavior after this commit is merged:

The file import doesn't raise a traceback.

---

Note on the fix:

The issue happened because in `_get_coda_file_statement()`, the date is expected to be on the index range 115-120 but the the decoding of the file in `_parse_bank_statement_file()` transformed a "€" in "Ôé¼" which moved the date to indexes 117-122. This wrong translation of encoding happened because cp850 was used - which doesn't support currency symbols - instead of utf_8 because the latter was stopped by a non matching regex that was missing the currency symbols.

This commits includes currency symbols in the validating regex so that the most appropriate encoding is validated as often as possible.

---

opw-4546281

Forward-Port-Of: odoo/enterprise#81329

Versions
--------
- 17.0+

Steps
-----
1. Create an event with an attendee limit of 1;
2. publish the event;
3. add a ticket to you cart;
4. go through checkout until your reach the payment page;
5. open a incognito window or different browser;
6. add same ticket to cart;
7. go to the payment step;
8. click "Pay now" and wait for confirmation;
9. go to previous window, and click "Pay now".

Issue
-----
The payment gets confirmed, but you land on an internal server error due to a lack of available seats for the event.

Cause
-----
Commit ffc9026361beb added a check before payment to ensure the tickets still had seats available. The event itself however can have a separate seat limit that isn't currently being checked.

Solution
--------
Add a check on the event's seat availability to `_validate_transaction_for_order`.

Also, in case there's a lack of seats, display the correct number of lacking seats for the order instead of `-available_seats`.

opw-4453539

Forward-Port-Of: odoo/odoo#201906
Forward-Port-Of: odoo/odoo#200400

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#201550
Forward-Port-Of: odoo/odoo#199127

In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed.

Steps to reproduce:
- Have a Loyalty Program configured as follows:
  - Program Type: Loyalty Card
  - Grant 1 point per $ spent
- Create a Loyalty card for [Partner]
- Open POS Session
- Add a [Partner] as customer
- Add product
- Leaving the order as it is, create a new order
- Add just a product
- Validate & Pay the second order

Issue: Loyalty points will be added to [Partner] Card, as if the order was actually paid

This occurs because we don't check that the order has been actually paid before processing rewards

opw-4538040

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

Forward-Port-Of: odoo/odoo#199108

In Point of sale promotion program may be auto applied to the order
whenever the conditions of the promotions are satisfied.
However, a promo 'buy x get y' is auto applied inconsistently when
comparing the output with the reward button (or applying the promotion on a sales
order)

Steps to reproduce:
- Have a promo program like follows:
  - Program Type: Buy X Get Y
  - Condition:
    - Minimum quantity: 2
    - Grant: 1 credit per order
    - Product: [PRODUCT]
  - Reward:
    - In exchange of: 1 credit
    - Product: [PRODUCT]
    - Quantity rewarded: 1
- Open POS Session
- Add 2x [Product]

Issue:
- "Free" [PRODUCT] line is added to the order with negative price

So the customer will buy 1 [PRODUCT] and get 2 that is not what we want
with the promo program
If we delete the reward line, click on reward button and choose again
the same promo we get the correct behavior:
- Exisitng [PRODUCT] line quantity raised to 3
- "Free" [PRODUCT] line added to the order with negative price

opw-4563825

Forward-Port-Of: odoo/odoo#199752

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing.

Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`).

Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior.

This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue.

fixes runbot-106895

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

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

Forward-Port-Of: odoo/odoo#202226
Forward-Port-Of: odoo/odoo#202009

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

- Install hr_timesheets
- Go to Timesheets > All Timesheets
- Use the week scale
- Scroll to the bottom => Take note of the last record (e.g.: Walter Horton)
- Now use a mobile viewport
- Make sure the week scale is still applied
- Scroll to the bottom => The last record is not the same one as the desktop view

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

The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height.

On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.

![image](https://github.com/user-attachments/assets/08f604e3-ae3e-4a73-86d9-41bd4dbfaf9a)

The `grid-template-rows` was set to auto on mobile in order to accomodate that case.

Using auto means we no longer have a consistent row height.

Solution
========

We restore the `gridTemplateRows` and allocate extra space when needed.

![image](https://github.com/user-attachments/assets/5254d7a6-0e32-4321-8e46-abcf0609dcaa)


opw-4208357

Forward-Port-Of: odoo/enterprise#81617
Forward-Port-Of: odoo/enterprise#80476

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81532
Forward-Port-Of: odoo/enterprise#81127

Description of the issue this commit addresses:

A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format.

---

Steps to reproduce:

1. Install l10n_be_coda
2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket.
3. A traceback is raised

---

Desired behavior after this commit is merged:

The file import doesn't raise a traceback.

---

Note on the fix:

The issue happened because in `_get_coda_file_statement()`, the date is expected to be on the index range 115-120 but the the decoding of the file in `_parse_bank_statement_file()` transformed a "€" in "Ôé¼" which moved the date to indexes 117-122. This wrong translation of encoding happened because cp850 was used - which doesn't support currency symbols - instead of utf_8 because the latter was stopped by a non matching regex that was missing the currency symbols.

This commits includes currency symbols in the validating regex so that the most appropriate encoding is validated as often as possible.

---

opw-4546281

Forward-Port-Of: odoo/enterprise#81329