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