Currently, when a discount reward is applied onto an order and a tip is added later, the discount gets also applied on the tip.

Steps to reproduce:
-------------------
* Make sure all demo data loyalty programs can also apply to the restaurant
* Make sure tipping is enabled in the restaurant
* Open restaurant
* Open a table, add items to the order
* Activate coupon code "10pc"
* Select payment
* On payment page, add a tip (10$)
* Go back to product page
> Observation: 10% discount is also applied on the tip

Why the fix:
------------
A tipping should never have a discount applied on it.

During the computation of the discountable amount we have 3 distinct flow (discount applies on the order, on the cheapest line, on some specific products)

- On the order: We always exclude tipping lines
- Cheapest line: When fetching the cheapest line amongst all lines we don't consider the tipping lines
- On specific: With the fix, tipping lines will always be excluded from the discountable lines. Even if the tip product was specified on the loyalty program. Should we still allow discounting tips if it was set in the program specifically?

We're using `is_discountable` instead for `is_tip` in case we want to extend the definition later on.

opw-6445364

Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types.

This results in invoice reports showing the identification number next to an incorrect label.

This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in
their respective invoice template to match the selected identification type.

Steps to reproduce:
- Install a latam localisation (Uruguay or Guatemala)
- Change company to that country's Company
- Create a partner located in said country, ensure the identification number is set to something else than the default one
- Create an invoice for the partner, confirm it, and then Send it
- In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label

opw-6087359

related to: https://github.com/odoo/odoo/pull/260159

Problem:
When the website_sale_renting module is uninstalled and you try to create a rental order with a product that has an optional rental product, the system crashes with a traceback. This happens because the rental start and end dates are passed to the product pricing calculations as plain text strings instead of proper date formats, which breaks the timezone math.

Solution:
This commit ensures that the rental start and end dates are converted into proper datetime formats before any duration or pricing calculations occur, preventing the error and allowing the products to be added to the rental order smoothly.

Steps to reproduce(runbot v18):
1. Install the Rental (sale_renting) and Website modules.
2. Uninstall the website_sale_renting module.
3. Create a rental product and configure another rental product as its optional product.
4. Open the Rental application and try to add the created product to a rental order.
5. A traceback is raised while calculating the rental price.

opw-6485776

Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera` to their accept attribute: a mimetype which is not an image is enough to get the generic chooser, and its camera, back.

https://issues.chromium.org/issues/40937303

That invalid mimetype was appended for everyone, while only the browsers based on Chromium on Android need it:

- the issue is an Android one, the desktop file dialogs are not concerned
- the native app builds its own file chooser out of the accept attribute, and the invalid mimetype makes it offer the document picker on a field which only accepts images
- Firefox and Safari are not based on Chromium and are not affected

The workaround is now limited to the browsers needing it, and the expression moved from the template to a getter, since it is no longer a simple concatenation.

Code made by Claude
Supervised by RFR

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

Forward-Port-Of: odoo/odoo#285643

Issue:
----------------------------------------
In the Planning Gantt view, when an employee's slots are split across several rows, all of them are greyed out except the last one, which correctly displays the employee's working hours.

Steps to reproduce:
----------------------------------------
- Have an employee with a running contract.
- Create two shifts for that employee on two different projects.
- Open Planning, switch to the Gantt view, and group by Resource, then by Project.
- Only one of the two rows for that employee shows the working hours; the other is greyed out.

Cause:
----------------------------------------
The grey background is applied by the Gantt view to any cell that has no matching working period, the same way it greys out days off.

The working periods, based on the employee's work intervals are computed in `gantt_resource_employees_working_periods()` and indexed by employee id in a plain dict (`row_per_employee_id`). When the same employee appeared in several rows, each new row overwrote the previous one in the dict, so only the last row kept a reference and got its working periods filled in.

Solution:
----------------------------------------
Group the rows per employee into a list instead of a single dict entry, and append the computed `working_periods` to every row belonging to that employee.

opw-6449130

### Steps to reproduce:
- Install `sale_subscription_timesheet` module
- Create a subscription (Order A) with delivered-timesheet products and log timesheets within its current period (e.g., January)
- Create a standard order (Order B) with delivered-timesheet products and log timesheets outside of Order A's period (e.g., March)
- Select both orders and invoice them simultaneously in a single batch (uncheck 'Consolidated Billing')
> Result: Order B's invoice is created but silently fails to link its March timesheets, because they fall outside Order A's January window.

### Cause of Issue:
In `_link_timesheets_to_invoice`, the `start_date` and `end_date` parameters are overwritten inside the invoice line loop when `_get_range_dates` is called. Because these variables are never reset per iteration, the first order that yields a date range locks in that window for every subsequent invoice line in the batch. Timesheets outside this leaked window are silently ignored.

Additionally, the `_get_range_dates` hook is invoked before verifying if the invoice line actually contains timesheet products, causing it to execute on empty recordsets (e.g. invoice line notes)

### Fix:
Prevent the date range leak by preserving the original parameter state of the dates and safely ensure the extension hook is never invoked with an empty recordset.

opw-6507110

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

Steps to reproduce:
===================
1. Enable the cookies bar on a website.
2. Set a malformed `website_cookies_bar` cookie in the browser (e.g. an empty value).
3. Open any frontend page.

=> Every frontend page returns a bare 500; the error page cannot
   render either, since it goes through the same code path.

Root cause:
===========
`_is_allowed_cookie('optional')` parses the `website_cookies_bar` cookie with `json_scriptsafe.loads` without guarding against invalid JSON. An empty or unparsable value raises `JSONDecodeError`.

The unguarded `loads` has existed since 16.0, but it was only reached in a few situational spots, so a bad cookie was harmless. It became reachable on every page render when [1] added an unconditional `_is_allowed_cookie('optional')` call to
`IrQWeb._prepare_frontend_environment` (run for every frontend QWeb render) and put its result in `_get_template_cache_keys`, so the value must be computed on every render. This is why 17.0 is unaffected and 18.0+ crash.

Fix:
====
Wrap the `loads` in a try/except on `ValueError` (superclass of `JSONDecodeError`) and fall back to `None`. A `None`/non-dict value already flows into the existing pre-16.0 compatibility branch, which resets the cookie (`max_age=0`) and lets the visitor choose again.

[1]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1

opw-6380116

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

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

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