## Versions:
16.0+

## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.

## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.

## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
  - 2 points granted per purchase (minimum $0).
  - Rewards:
    - 5% discount on "Simple Pen" (costs 1 point).
    - 10% discount on "Whiteboard Pen" (costs 1 point).
  - Create a Quotation with "Simple Pen" and "Whiteboard Pen".
  - Confirm the Quotation into a Sales Order.
  - Apply promotions:
    - The first reward applies correctly
    - The second reward does not apply

opw-4753472

Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342

Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post.

**Steps to reproduce:**

- Install the `website_forum` module.
- Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`.
- Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`.
- Click on `Post Your Question`.

**Error:**
`ValueError: invalid literal for int() with base 10: 'retour affectif rapide'`

**Root Cause:**

After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2].

**Fix:**
This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input,  similar to [3].

Also updated the test case at [4], to click `Create option` to save the tags.

[1]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61

[2]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304

[3]:
https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80

[4]:
https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37

sentry-6761920887

Forward-Port-Of: odoo/odoo#227185
Forward-Port-Of: odoo/odoo#220058

**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App

**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```


**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback

Fix:
- Adjust the method to accept multiple contracts

opw-5045306

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

Forward-Port-Of: odoo/odoo#225521

**Steps to Reproduce:**

1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that  install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.

**Issue**

why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking.  During render checking the  ``videocall_redirection``  field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.

**Fix:**

 For fixing this checking is the fields syncable with calendar or not

```
 File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
    event.access_token = uuid.uuid4().hex
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
    res = super().write(vals)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
    self._check_modify_event_permission(values)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
    raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082


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

Forward-Port-Of: odoo/odoo#226890

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

Issue Before This Commit:
============================
When only the quants/move line were changed without modifying the quantity,
the system automatically marked components as consumed (manual consumption
and picked boolean were set). This created confusion for the user since
no actual consumption took place.

Steps to Reproduce:
============================
- Install the `mrp` module.
- Create a tracked product (lot/serial) with quants.
- Create and confirm an MO having that product as a component.
- Change only the quants (e.g., location of the quant, not quantity);
  notice that manual consumption and picked boolean are set.

Cause of the Issue:
===========================
This issue occurs when clicking the 'Details' button (`action_show_details` 
method) on a stock move. That action passes the context `force_manual_consumption`, 
based on that which directly sets the `manual_consumption` and `picked` booleans in the 
`write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276).

With This Commit:
============================
Manual consumption and picked boolean are no longer set when only quants
(not quantity) are changed. Component consumption is now triggered only if
the quantity differs from the demand, ensuring consistency and avoiding
confusion for the user.

This fix avoids unintended behaviour by ensuring that the picked and manual
consumption booleans change only when the quantity differs from the demand.

TaskID:- 5062365

Forward-Port-Of: odoo/odoo#225386

If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised.

Steps to reproduce:
-------------------
* Create a loyalty cards program
* Set company to the current company
* Create a branch company for the current one
* Switch to branch company
* Create a sale order, no need to add products, just a partner
* Try to confirm the order
> Observation: Access Error:
> Sorry, Mitchell Admin (id=2) doesn't have 'create' access to:
> -History for Loyalty cards and Ewallets (loyalty.history)

Why the fix:
------------
Here's where the access error is being triggered:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106

Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history.

Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company.

opw-5055999

Forward-Port-Of: odoo/odoo#226226

In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations.

To reproduce the bug:
1- Create a db with, stock, mrp, sale installed.
2- Unarchive `MTO` route.
3- Set `Security Lead` Time in Setting.
4- Create two warehouses wh1, wh2.
5- In wh1, set `Manufacture to Resupply` to True.
6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1.
7- Create a product and track inventory.
8- Create a BOM for the product.
9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product.
10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote.
11- Open MO. Security lead time is considered twice in dates calculations which is mistake.

To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected.

This issue is reproduced because this condition is not sufficient to ensure it is called once:
https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657

The above condition is written to ensure we are adding the delay only when move location is warehouse stock location.

This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2.

To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location.

related: #112325

opw-4889642

Forward-Port-Of: odoo/odoo#226712
Forward-Port-Of: odoo/odoo#224232

[FIX] account_reports: external value check lock date

This commit add the check that protects external values from being edited out of the lock date.
For example when the tax report is submitted, the user is not supposed to modify any external values anymore.

To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow.

Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error.

task-5012442

Forward-Port-Of: odoo/enterprise#94641
Forward-Port-Of: odoo/enterprise#92949

This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange

If a user ser the validated_overtime_hours to a value that is not the one in overtime_hours, upon changing the check_out time we will trigger the compute for both those fields. Overtime_hours calculates it's value based on attendance.overtime model, which is not being updated here, hence it will have the same value. Validate_overtime_hours in the other hand will be updated since there is a write in overtime_hours (even though with the same value) and this will mark the field to be updated when a web_save happens. Now when the save happens the overtime_hours is updated but even though validate_overtime_hours depends on it, it won't be updated since it's being writen to, as a field to be updated

This fix aims to prevent writing to overtime_hours when there is no real need to, preventing the described issue

opw-4806193

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

Forward-Port-Of: odoo/odoo#222832

The `hr_contract` table is renamed to `hr_version` as part of the https://github.com/odoo/upgrade/blob/3bea30d1fd0cd202006da4ad11e00e283cbc78d0/migrations/hr/saas~18.4.1.1/pre-migrate.py#L29, script, which is executed before any `hr_contract_salary` script, including module ones. As a result, any database from 18.3 to 18.4+ with `hr_contract_salary` < 2.1 will run into:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 181, in load_module_graph
    migrations.migrate_module(package, 'pre')
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 220, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 257, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/enterprise/saas-18.4/hr_contract_salary/upgrades/saas~18.3.2.1/pre-unarchive-partially-signed-offers.py", line 4, in migrate
    cr.execute(
  File "/home/odoo/src/odoo/saas-18.4/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
psycopg2.errors.UndefinedTable: relation "hr_contract" does not exist
LINE 4:                 FROM hr_contract c
                             ^
```

As a fix, the query is moved into the `hr` script mentioned above.

see: https://github.com/odoo/upgrade/pull/8466

opw-5071923
upg-3121357
tbg-2136

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App

**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```


**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback

Fix:
- Adjust the method to accept multiple contracts

opw-5045306

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

Forward-Port-Of: odoo/odoo#225521

If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised.

Steps to reproduce:
-------------------
* Create a loyalty cards program
* Set company to the current company
* Create a branch company for the current one
* Switch to branch company
* Create a sale order, no need to add products, just a partner
* Try to confirm the order
> Observation: Access Error:
> Sorry, Mitchell Admin (id=2) doesn't have 'create' access to:
> -History for Loyalty cards and Ewallets (loyalty.history)

Why the fix:
------------
Here's where the access error is being triggered:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106

Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history.

Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company.

opw-5055999

Forward-Port-Of: odoo/odoo#226226

[FIX] tools: Fixed AI field prompt access rights
Description of the issue/feature this PR addresses:
'Member' users can use the AI field button when the prompt contains standard field references. When the prompt contains a Studio field reference, there is an error message stating 'email template editor' access is required.

Current behavior before PR:
-Create an internal 'Member' user
-Add a 'user' group for the app you want to test on (bug spotted in Helpdesk).
-Make a plain text Studio field
-Make a text AI field where the prompt references the plain text Studio field you just created.
-Make a text AI field where the prompt references a standard available field.
-Log into the database as the 'Member' user
-Push the 'AI' button on each of the two fields you created.
-The one referencing the standard field should populate as normal; the one referencing the Studio field will trigger an error message asking for 'Email template editor access'.

Desired behavior after PR is merged:

Allowing AI fields unrestricted access to render template when stuudio field is used to avoid access error.

Task-5016767

This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange

If a user ser the validated_overtime_hours to a value that is not the one in overtime_hours, upon changing the check_out time we will trigger the compute for both those fields. Overtime_hours calculates it's value based on attendance.overtime model, which is not being updated here, hence it will have the same value. Validate_overtime_hours in the other hand will be updated since there is a write in overtime_hours (even though with the same value) and this will mark the field to be updated when a web_save happens. Now when the save happens the overtime_hours is updated but even though validate_overtime_hours depends on it, it won't be updated since it's being writen to, as a field to be updated

This fix aims to prevent writing to overtime_hours when there is no real need to, preventing the described issue

opw-4806193

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

Forward-Port-Of: odoo/odoo#222832

[FIX] account_reports: external value check lock date

This commit add the check that protects external values from being edited out of the lock date.
For example when the tax report is submitted, the user is not supposed to modify any external values anymore.

To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow.

Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error.

task-5012442

Forward-Port-Of: odoo/enterprise#92949

ISSUE
=====

Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when manage_capacity is False.

However, this broke the booking flow when enabling a payment on the appointment type as well, for resources with capacity > 1. More specifically, as soon as the remaining capacity is lower than the resource's own capacity.

STEPS TO REPRODUCE
==================

0. Install payment_demo, in order to be able to test the payment issue. Install website_appointment_sale to ease the testing too.
1. Create an appointment type for 'Resources', enable 'Up-front payment'.
2. Set a new resource with capacity = 2 on the appointment type.
3. Make sure manage_capacity is False, and number of simultaneous appointments (max_bookings) is set to 1.
4. Go to the front end and pick any slot.
5. Fill the form and 'proceed to payment'
6. Try to 'pay now'
7. You get a validation error message telling you that the slot is not available anymore. But it is not the case since it is a new type and new resource.

FIX
===

For resources, created booking lines were setting capacity_used to the resource's capacity, unless shared. (meaning: the resource is completely used, even if the reserved quantity is smaller). It made sense before but not for this new feature. It should only use 1 capacity, as we count the number of different simulatenous appointments, and it is unrelated to the resource's own capacity.

When creating the meeting at the end of the regular flow, the computed field on capacity_used on appointment.booking.line will set it to 1 when manage_capacity is False. Hence, no issue will happen there in practice as the meeting is always created in that case and capacity_used updated.

However, when enabling a payment, we create a calendar.booking instead, with calendar.booking.lines. And based on those, we evaluate availability when checking the cart before going to payment.

Those are simply created from values in the controller, and the model is much simpler. Therefore, we fix the issue by manually setting the capacity_used to 1 when creating the booking lines in the front-end booking flow, in the case of an appointment without capacity management.

Task-4963012

Forward-Port-Of: odoo/enterprise#94434
Forward-Port-Of: odoo/enterprise#91700

### Steps to reproduce:
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner
- Pay with "Swiss ISO20022"
- Create a batch payment with that payment and validate
- In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId))

### Cause:
The code directly inputs the value of `clearing_number` in `ClrSysMmbId`.

### Solution:
Add `MmbId` to contain the clearing number.

### Note:
The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`.

This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations.

opw-4872507

Forward-Port-Of: odoo/enterprise#94460

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

## **Issue Before This Commit:**
In the workcenter planning view, the total hours displayed were misleading,
as they always showed 24 hours of the day instead of the workcenter’s
defined working hours.
This caused confusion for users since the displayed total hours did not
match the actual available working time of the workcenter.

## **Steps to Reproduce:**
- Create a Manufacturing Order (MO).
- Add "Drawer" as the product.
- Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM.
- Set the quantity to produce as 10.
- Confirm the MO and plan it.
- Open the planning view and notice that the total hours count
  incorrectly shows 24 hours instead of the defined working hours.

## **Cause of the issue:**
The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486),
as the related changes were not adapted here.
Because of that, pill.record.workcenter_id[0] returns an undefined value.

## **With This Commit:**
The calculation of total hours has been corrected to consider only
the workcenter’s defined working hours.
Users now see accurate hours in the planning view, making it easier
to plan and schedule work orders reliably.

task - 4900885

Forward-Port-Of: odoo/enterprise#93035

Prior to this commit, the attribute previewer was not properly rendered on mobile in the "List thumbnails" and "List grid" product designs.

Also, since the attribute previewer was not updated when resizing the window in edit mode, it caused layout issues.

This commit updates the attribute previewer to ensure it renders correctly in all cases.

task-5016573

---

### Update attribute preview in edit mode
| | edit mode | normal mode |
|--------|--------|--------|
| 19.0 | <img width="1065" height="932" alt="Capture d’écran 2025-09-11 à 11 43 47" src="https://github.com/user-attachments/assets/33c3386e-c07b-4b60-bde5-69152c1b91c5" /> | <img width="1065" height="933" alt="Capture d’écran 2025-09-11 à 11 43 57" src="https://github.com/user-attachments/assets/9e046721-7afe-4109-8a2f-6168f5ada89e" /> |
| this branch | <img width="1346" height="975" alt="Capture d’écran 2025-09-11 à 14 48 35" src="https://github.com/user-attachments/assets/8166fbad-41ba-4bf1-9aff-78daf532f112" /> | <img width="1355" height="929" alt="Capture d’écran 2025-09-11 à 14 48 54" src="https://github.com/user-attachments/assets/61b3ad5a-bf15-43cf-8ab2-e04886d8b876" /> |

### Attribute preview in mobile

| | 19.0 | this branch |
|--------|--------|----------|
| List thumbnail | <img width="410" height="211" alt="Capture d’écran 2025-09-11 à 14 53 12" src="https://github.com/user-attachments/assets/c7cadadd-87dd-4e33-9d78-39027fd68602" /> | <img width="409" height="200" alt="Capture d’écran 2025-09-11 à 14 53 26" src="https://github.com/user-attachments/assets/9f938485-6421-453d-89fa-61cd0db26e72" /> |
| List thumbnail | <img width="818" height="386" alt="image" src="https://github.com/user-attachments/assets/ce87f4a1-9387-4cad-9098-0bb9ca085162" /> | <img width="406" height="178" alt="Capture d’écran 2025-09-11 à 14 54 29" src="https://github.com/user-attachments/assets/08496b4a-14c8-4090-85a5-db09dcf47bf0" /> |
| List grid | <img width="405" height="184" alt="Capture d’écran 2025-09-11 à 14 58 53" src="https://github.com/user-attachments/assets/ff10b4ce-8cb1-49c9-823e-34f354a25b81" /> | <img width="404" height="175" alt="Capture d’écran 2025-09-11 à 14 59 37" src="https://github.com/user-attachments/assets/eb01f787-17bd-4c02-b840-09d74b24a274" /> |
|List grid | <img width="409" height="159" alt="Capture d’écran 2025-09-11 à 14 59 57" src="https://github.com/user-attachments/assets/c6e73b57-eb02-4450-b52d-872aed179671" /> | <img width="408" height="144" alt="Capture d’écran 2025-09-11 à 15 00 07" src="https://github.com/user-attachments/assets/cce19acc-3d26-4ae4-8945-55025bc64490" /> |

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

Use correct domain to compute new orderlines upon clicking "Add All" from purchase catalog suggestion feature.

REASON: Typo in rush before freeze on which context to use: 
BEFORE: `domain = fields.Domain.AND([domain, self.env.context.get('domain')])`
AFTER: `domain = fields.Domain.AND([domain, suggest_ctx.get('domain')])`

Separated in 2 commits for review but they can be squashed on merge. 
Fixed typo above in first commit (along some other relevant changes) 
The second commit is just some unrelated cleaning up, and the following small changes:

- Moves In the order filter out of Good / Service filter group.
- Clamp suggestion percent factor between 0-999 (previously 0-inf)
- Removes the Activate text from the Suggest Toggle and cleans spacing.
- Put suggestion back on top of sections in SearchPanel (It was on top but then a PR for search panel sections inadvertently moved it below sections) 
- Change default suggest state to OFF (first time ever, afterwards state is saved/loaded from localStorage).

Original PR: odoo/odoo#218343 
Original task: task [#4783508](https://www.odoo.com/odoo/project/966/tasks/4783508)
Bug ticket: task [#5076240](https://www.odoo.com/odoo/project/966/tasks/5076240)

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

### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appears as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result, the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, taxes with `['taxImpact']['accounting'] == 'none'` should be part of the accounting: no line should be created for this tax. So we filter them out in `_get_external_taxes`.

We also log these taxes in the chatter to keep a trace of them. As the parameter `'accounting': 'none'` is linked with the tax and not the line, if a tax on one line has `'accounting': 'none'` then the same tax will also have 'accounting': 'none' on all other lines. We use this to fetch all non accounting taxes, then we use the summary to construct the message like it was done before.

The logging in the bridge with pos needed to ba adapted because now the taxes may not be unarchived as they are ignored when they have `'accounting': 'none'`.

opw-4964315

## Versions:
16.0+

## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.

## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.

## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
  - 2 points granted per purchase (minimum $0).
  - Rewards:
    - 5% discount on "Simple Pen" (costs 1 point).
    - 10% discount on "Whiteboard Pen" (costs 1 point).
  - Create a Quotation with "Simple Pen" and "Whiteboard Pen".
  - Confirm the Quotation into a Sales Order.
  - Apply promotions:
    - The first reward applies correctly
    - The second reward does not apply

opw-4753472

Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342

In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations.

To reproduce the bug:
1- Create a db with, stock, mrp, sale installed.
2- Unarchive `MTO` route.
3- Set `Security Lead` Time in Setting.
4- Create two warehouses wh1, wh2.
5- In wh1, set `Manufacture to Resupply` to True.
6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1.
7- Create a product and track inventory.
8- Create a BOM for the product.
9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product.
10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote.
11- Open MO. Security lead time is considered twice in dates calculations which is mistake.

To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected.

This issue is reproduced because this condition is not sufficient to ensure it is called once:
https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657

The above condition is written to ensure we are adding the delay only when move location is warehouse stock location.

This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2.

To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location.

related: #112325

opw-4889642

Forward-Port-Of: odoo/odoo#226712
Forward-Port-Of: odoo/odoo#224232

**Steps to Reproduce:**

1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that  install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.

**Issue**

why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking.  During render checking the  ``videocall_redirection``  field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.

**Fix:**

 For fixing this checking is the fields syncable with calendar or not

```
 File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
    event.access_token = uuid.uuid4().hex
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
    res = super().write(vals)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
    self._check_modify_event_permission(values)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
    raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082


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

Forward-Port-Of: odoo/odoo#226890

## **Issue Before This Commit:**
In the workcenter planning view, the total hours displayed were misleading,
as they always showed 24 hours of the day instead of the workcenter’s
defined working hours.
This caused confusion for users since the displayed total hours did not
match the actual available working time of the workcenter.

## **Steps to Reproduce:**
- Create a Manufacturing Order (MO).
- Add "Drawer" as the product.
- Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM.
- Set the quantity to produce as 10.
- Confirm the MO and plan it.
- Open the planning view and notice that the total hours count
  incorrectly shows 24 hours instead of the defined working hours.

## **Cause of the issue:**
The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486),
as the related changes were not adapted here.
Because of that, pill.record.workcenter_id[0] returns an undefined value.

## **With This Commit:**
The calculation of total hours has been corrected to consider only
the workcenter’s defined working hours.
Users now see accurate hours in the planning view, making it easier
to plan and schedule work orders reliably.

task - 4900885

Forward-Port-Of: odoo/enterprise#93035

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

Issue Before This Commit:
============================
When only the quants/move line were changed without modifying the quantity,
the system automatically marked components as consumed (manual consumption
and picked boolean were set). This created confusion for the user since
no actual consumption took place.

Steps to Reproduce:
============================
- Install the `mrp` module.
- Create a tracked product (lot/serial) with quants.
- Create and confirm an MO having that product as a component.
- Change only the quants (e.g., location of the quant, not quantity);
  notice that manual consumption and picked boolean are set.

Cause of the Issue:
===========================
This issue occurs when clicking the 'Details' button (`action_show_details` 
method) on a stock move. That action passes the context `force_manual_consumption`, 
based on that which directly sets the `manual_consumption` and `picked` booleans in the 
`write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276).

With This Commit:
============================
Manual consumption and picked boolean are no longer set when only quants
(not quantity) are changed. Component consumption is now triggered only if
the quantity differs from the demand, ensuring consistency and avoiding
confusion for the user.

This fix avoids unintended behaviour by ensuring that the picked and manual
consumption booleans change only when the quantity differs from the demand.

TaskID:- 5062365

Forward-Port-Of: odoo/odoo#225386

Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post.

**Steps to reproduce:**

- Install the `website_forum` module.
- Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`.
- Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`.
- Click on `Post Your Question`.

**Error:**
`ValueError: invalid literal for int() with base 10: 'retour affectif rapide'`

**Root Cause:**

After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2].

**Fix:**
This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input,  similar to [3].

Also updated the test case at [4], to click `Create option` to save the tags.

[1]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61

[2]:
https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304

[3]:
https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80

[4]:
https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37

sentry-6761920887

Forward-Port-Of: odoo/odoo#227185
Forward-Port-Of: odoo/odoo#220058

Description of the issue this PR addresses:

Issue 1:

Steps to Reproduce:

- Open the website.
- Create a mega menu.
- Enter edit mode.
- Change the mega menu template to “Cards”.
- Click on any option available in the mega menu.
- A link popover will open.
- Click the Edit link button in the popover.
- Click the Apply button to save the link.
- A traceback occurs.

The error occurs because the text-wrap class is applied to the link. When the
hasColor method is triggered, it checks whether a.nav-link has a text color
class. However, TEXT_CLASSES_REGEX incorrectly matches text-wrap as a color
class. As a result, the removeColor method attempts to remove it and triggers
_applyColor to remove the color, but in _applyColor method it does not find any
color to remove on selected text. As a result, the removeColor process enters an
infinite loop, which eventually leads to a traceback.

Solution:

Update TEXT_CLASSES_REGEX so that it only matches valid text color classes and
excludes formatting classes such as text-wrap, text-center, etc.

Issue 2:

This commit ensures that the remove format action is disabled when a button
(.btn element) has custom color or background color applied.

Because buttons include padding, there is no proper way to remove a background
color from a partially selected button, so the action must be ignored in this
case.

task-5062715


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

Forward-Port-Of: odoo/odoo#226722
Forward-Port-Of: odoo/odoo#225477

Currently, an error occurs when user tries to select any measure in cohort view.

Steps to replicate:
- Install `sale_management` and `web_studio`.
- Open the Sales app and turn on studio mode.
- Under the Views tab, turn on cohort view.
- Under the Measures field, select any value and observe the error appearing in the terminal.

Error:
`ValueError: Invalid aggregate method 'None' for 'create_date:None'`

Cause:
- The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`.

- This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view.

Solution:
- Corrected the choices of Measure field to `measureFields`.

- Also added a condition to allow only those fields that have an aggregator
  (for some fields like `sequence` that dont have an aggregator).

- Also removed context field from arguments [2] in the rpc call as function doesnt need it [3]
  (This shows warning on runbot as well).

[1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30

[2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87

[3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805

sentry-6781792463

Forward-Port-Of: odoo/enterprise#94450
Forward-Port-Of: odoo/enterprise#91599

**Steps to reproduce:**

1-Install the sale_subscription module.
2-Create a Sale Order and choose any recurring plan. 
3-In the Sale Order line add subscription product (e.g.,Office Cleaning Service)
4-Add the same product again in a new line with a 100% discount. 
5-Confirm the order, create an invoice, and confirm it.
6-Go back to the Sale Order → Other Info section: the invoice status is shown as Nothing to Invoice, 
even though an invoice was already created and another one can still be generated.

**Issue:**

- The invoice status is incorrectly set to Nothing to Invoice on the Sale Order.

**Cause:**

https://github.com/odoo/enterprise/blob/486965b5617ff90b1c32be106ef2b538726bedb9/sale_subscription/models/sale_order_line.py#L72-L75

- In sale_subscription, when a line has a 100% discount, its subtotal becomes zero and this code sets the line’s invoice status to no (nothing to invoice).

https://github.com/odoo/odoo/blob/ec2614db4df5b3177387a129f6156ee9844fb544/addons/sale/models/sale_order.py#L636-L642

- In sale, the `_compute_invoice_status` method then aggregates this into the Sale Order, resulting in a wrong invoice status.

**Solution:**

- Add an extra condition in sale_subscription to properly detect future_line and prevent zero-subtotal lines with 100% discount from incorrectly setting the Sale Order status to Nothing to Invoice.

opw - 4999495

steps to reproduce:
-------------------
1. Install Employees, Timesheets, Projects
2. Create 2 companies
3. On each company, create an employee for the same related user
4. Create a project without setting a company (making it a global project).
5. Enable both companies in the systray
6. Try to log a timesheet on the global project.

issue:
------
A ValidationError is raised:
"Timesheets must be created with an active employee in the selected companies."

cause:
------
During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381

If the project has no company set, `company_id `becomes **False**.

This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215

solution:
---------
Use `self.env.company` if company_id is missing(or False) in the vals.

opw-4892449

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

Forward-Port-Of: odoo/odoo#223846

Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.

1. Directly create an invoice.
    - Create and confirm a subscription with a combo product.
    - Create an invoice for this subscription and try to confirm it.
    - Validation error shown in display and error generated in log

2.  When cron "Payment: Post-process transactions" trigger:
    - Enable the Automatic Invoice option in the Subscription settings.
    - Activate a demo payment provider (e.g. Demo: Payment Provider).
    - Create and confirm a subscription that includes a combo product.
    - Click on "Pay" to process the subscription payment.
    - An error occurs when the above-mentioned cron is triggered, and it
      tries to create an invoice for a subscription order.

Error: `new row for relation "account_move_line" violates check constraint
 "account_move_line_check_accountable_....`

This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`

This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].

[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309

sentry-6763423503

Description of the issue/feature this PR addresses:
This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail.

Current behavior before PR:
Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data.

Desired behavior after PR is merged:
After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes.



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

### Issue
PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError.

### Solution
Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type.

### Affected Reports
- `account.report_original_vendor_bill` - Vendor bill reports
- `hr_expense.report_expense_sheet` - Expense sheet reports

### Affected Versions
- 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense)

### Reproduction Steps

#### Option A: HR Expense Report
1. Create HR expense record
2. Add attachment with type=url/cloud_storage pointing to valid PDF URL
3. Link attachment to hr.expense record
4. Generate expense report → TypeError occurs

#### Option B: Vendor Bill Report
1. Create vendor bill (account.move)
2. Add attachment with type=url/cloud_storage pointing to valid PDF URL
3. Link attachment to account.move record
4. Print Original Vendor Bill → TypeError occurs

### Error Details
```python
TypeError: a bytes-like object is required, not 'bool'
  at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream
  from /odoo/addons/hr_expense/models/ir_actions_report.py:29
```

#### Reference
Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view

OPW-5036638

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

**Steps to reproduce:**
- Install Accounting

- In Accounting settings, activate "Cash Basis"
- Create/modify a tax with "Tax Exigibility" set to "Based on Payment"
- Set an account as "Cash Basis Transition Account"

- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - [Price] 200.0
    - [Taxes] The cash basis tax (e.g. 15%)
- Confirm the invoice

- Go to "Bank" journal
- Create a bank statement for a lower amount than the invoice (e.g. $200)
- Match the statement with the invoice from the "Match Existing Entries" tab
- Select the added line and click on "fully paid" link
=> A new line with the amount difference should be added
- On the new line, select an expense account and the cash basis tax 
=> A new tax line should be added (e.g. $3.91)
- Validate
- Go to "Accounting / Reporting / Statement Reports / Tax Report"

**Issue:**
The amount of the Tax is equal to:
[Tax amount of the invoice] - 2 * [Tax amount of the difference line] = $30 - 2 * $3.91 = $22.18
which is not correct.
The tax amount of the difference line (coming from the bank reconciliation widget) is taken twice into account.

**Cause:**
A cash basis move is created for the tax line created in the bank reconciliation widget.
This move is using the same tax account as debit and credit account and is directly reversed using the same account.
No cash basis move should be created for that line because the tax line is added while reconciling a bank statement, which means the tax should have been received.

**Solution:**
Do not create a cash basis move for journal entries made in a bank or cash journal.

opw-4663059




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

Forward-Port-Of: odoo/odoo#225151

**Steps to reproduce:**
- Install Accounting

- In Accounting settings, activate "Cash Basis"
- Create/modify a tax with "Tax Exigibility" set to "Based on Payment"
- Set an account as "Cash Basis Transition Account"

- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - [Price] 200.0
    - [Taxes] The cash basis tax (e.g. 15%)
- Confirm the invoice

- Go to "Bank" journal
- Create a bank statement for a lower amount than the invoice (e.g. $200)
- Match the statement with the invoice from the "Match Existing Entries" tab
- Select the added line and click on "fully paid" link
=> A new line with the amount difference should be added
- On the new line, select an expense account and the cash basis tax 
=> A new tax line should be added (e.g. $3.91)
- Validate
- Go to "Accounting / Reporting / Statement Reports / Tax Report"

**Issue:**
The amount of the Tax is equal to:
[Tax amount of the invoice] - 2 * [Tax amount of the difference line] = $30 - 2 * $3.91 = $22.18
which is not correct.
The tax amount of the difference line (coming from the bank reconciliation widget) is taken twice into account.

**Cause:**
A cash basis move is created for the tax line created in the bank reconciliation widget.
This move is using the same tax account as debit and credit account and is directly reversed using the same account.
No cash basis move should be created for that line because the tax line is added while reconciling a bank statement, which means the tax should have been received.

**Solution:**
Do not create a cash basis move for journal entries made in a bank journal.

opw-4663059

Forward-Port-Of: odoo/enterprise#93735

As I mentioned in the query below, multiple grouped product.template records with the same supplier_taxes_id are being modified with the default purchase tax (account_purchase_tax_id),which leads to a memory error. To prevent this, I have used an INSERT query.

```sql
SELECT tax_id, COUNT(*) AS product_count
FROM product_supplier_taxes_rel
GROUP BY tax_id
ORDER BY product_count DESC;
 tax_id | product_count
--------+---------------
     15 |       1262126
    156 |        343332
    114 |         36363
     47 |         10132
     23 |           202
    546 |            11
    474 |             5
    782 |             2
    666 |             2
   1188 |             2
   1318 |             1
      3 |             1
(12 rows)
```

- Traceback
```python
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1314, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 515, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
    migrate(self.cr, installed_version)
  File "/home/odoo/src/odoo/17.0/addons/l10n_ch/migrations/11.3/end-migrate.py", line 8, in migrate
    env["account.chart.template"].try_loading("ch", company)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
    return self._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/point_of_sale/models/chart_template.py", line 22, in _load
    result = super()._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 214, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 10, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/17.0/addons/stock_account/models/account_chart_template.py", line 12, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 669, in _post_load_data
    sudoed_products_purchase._force_default_purchase_tax(company)
  File "/home/odoo/src/odoo/17.0/addons/account/models/product.py", line 130, in _force_default_purchase_tax
    product_grouped_by_tax.supplier_taxes_id += default_supplier_taxes
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1322, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/odoo/17.0/addons/website_sale/models/product_template.py", line 176, in write
    return super().write(vals)
  File "/home/odoo/src/odoo/17.0/addons/rating/models/rating_mixin.py", line 100, in write
    result = super(RatingMixin, self).write(values)
  File "/home/odoo/src/odoo/17.0/addons/stock_account/models/product.py", line 55, in write
    res = super(ProductTemplate, self).write(vals)
  File "/home/odoo/src/odoo/17.0/addons/mrp/models/product.py", line 74, in write
    return super().write(values)
  File "/home/odoo/src/odoo/17.0/addons/stock/models/product.py", line 921, in write
    return super(ProductTemplate, self).write(vals)
  File "/home/odoo/src/odoo/17.0/addons/product/models/product_template.py", line 502, in write
    res = super(ProductTemplate, self).write(vals)
  File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 311, in write
    return super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_activity_mixin.py", line 250, in write
    return super(MailActivityMixin, self).write(vals)
  File "/home/odoo/src/odoo/17.0/addons/website/models/mixins.py", line 218, in write
    return super(WebsitePublishedMixin, self).write(values)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4444, in write
    field.write(self, value)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4337, in write
    self.write_batch([(records, value)])
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4358, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4957, in write_real
    y_to_xs[y].add(x)
  File "/home/odoo/src/odoo/17.0/odoo/tools/misc.py", line 1136, in add
    self._map[elem] = None
MemoryError
```
opw - 4544050
upg - 2459515

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