In this commit:
------------------
- Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx)
  orders as discussed with the Fiskaly team.
- `Initialize order transactions` with an empty payload when the `first product` is added.
- Start `receipt transactions` with an empty payload when the `first payment line` is added.
- For retail flows, no intermediate order updates are sent to Fiskaly before finalization.
- For restaurant flows, create additional transaction updates during kitchen synchronization.
  Ensure already synchronized products are not resent, and only newly added or updated
  quantities are included in the payload.
- `Finalize order and receipt transactions` with complete order lines and payment details
  when we validate the order.

task: 6208963

Reference:
<img width="1863" height="1285" alt="de_tss_flow" src="https://github.com/user-attachments/assets/9140788e-7948-4a08-9f11-27197b22ca8b" />

Forward-Port-Of: odoo/enterprise#120529
Forward-Port-Of: odoo/enterprise#117526

Steps to reproduce:
1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya.
2. Sell and validate an order.
3. Refund it from the POS and validate the refund order.

Issue:
- A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`.

Cause:
- When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call.
- The same multi-id list is also produced whenever several orders created offline get synced together once back online.

Solution:
- `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list.
- Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case.

opw-6364221

Forward-Port-Of: odoo/enterprise#123043

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#122440
Forward-Port-Of: odoo/enterprise#114876

Before this commit, _compute_l10n_be_computed_seniority looped over cp200_versions but still read self.employee_id and self.l10n_be_scale_seniority, so when Odoo batched multiple CP200 versions together, the whole recordset was passed to _get_first_version_date(), crashing with a singleton error.

After this commit, the loop correctly uses version.employee_id and version.l10n_be_scale_seniority instead.

Traceback (important part):

```py
    File "/home/odoo/src/enterprise/l10n_be_hr_payroll/models/hr_version.py", line 1508, 
  in _compute_l10n_be_computed_seniority                                                 
      company_seniority = relativedelta(fields.Date.today(),                             
  self.employee_id._get_first_version_date()).years                                      
                                                                                         
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                             
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 621, in             
  _get_first_version_date                                                                
      versions = self._get_last_consecutive_versions(date_limit)                         
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                         
    File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 595, in             
  _get_last_consecutive_versions                                                         
      self.ensure_one()                                                                  
    File "/home/odoo/src/odoo/odoo/orm/models.py", line 5406, in ensure_one              
      raise ValueError("Expected singleton: %s" % self)                                  
  ValueError: Expected singleton: hr.employee(30, 1)           
  ```

task-6377630

Steps to reproduce:
------------------------------------
1. Install the Knowledge module.
2. Open any article.
3. Click the header icon. If no icon is present, add one from the Actions menu.
4. Click the header icon again.
5. Click Remove icon from the emoji picker.

Observation:
------------------------------------
A traceback is raised when removing the header icon. 
```
TypeError: Cannot set properties of undefined (setting 'scrollTop')
```

Issue:
------------------------------------
The emoji picker component updates its scroll position through a grid reference.

After this PR - https://github.com/odoo/odoo/pull/269588, the emoji picker was migrated to Owl 3, which changed the way component references are handled. The header icon removal flow still uses the previous ref access pattern, causing the grid reference to be `undefined` when attempting to update `scrollTop`, resulting in a traceback.

Solution:
------------------------------------
Update the syntax for accessing the ref signal.

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#120983
Forward-Port-Of: odoo/enterprise#116430

## Description of the issue/feature this PR addresses:
Turkish accounting applies different exchange rates depending on whether
the company is collecting foreign currency or paying it out. TCMB publishes
both buying and selling rates daily but `currency_rate_live` only keeps
the average, so accountants currently correct the rate by hand on every
invoice and bill.

## Current behavior before PR:
The TCMB daily update stores only the averaged rate on `res.currency.rate`.
Invoices and bills use that same rate, and users have to adjust it
manually per document.

## Desired behavior after PR is merged:
- Both the buying and selling rates are stored on `res.currency.rate`
  next to the average.
- Customer invoices and vendor bills get a Rate Type field, defaulting
  to "buying" for invoices and vendor refunds and to "selling" for bills
  and customer refunds. The user can override before posting.
- The selected rate is written to `invoice_currency_rate`. The lookup
  uses the rate dated the document's date, or the most recent rate
  before it when no rate exists for that exact date.
- Only TR companies with TRY as base currency are affected.

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

`sync_participants` calls `action_set_unlink` on every participant whose record is no longer in the campaign domain, and `action_set_unlink` writes "Record deleted" on each scheduled trace. The removed bucket also contains records that still exist but no longer match the campaign filter, so the cancelled trace dialog shows "Record deleted" even when the record was only filtered out.

In `sync_participants`, the to_remove participants are split between those whose record still exists in the database (filtered out by the campaign domain) and those whose record was actually deleted. `action_set_unlink` accepts an optional `trace_message` argument, defaulting to "Record deleted", and the filtered-out batch passes "Record no longer matches campaign filter" so the cancelled trace dialog reflects the real cause.

Steps to reproduce:
1. Install Marketing Automation and CRM.
2. Open Marketing Automation, create a campaign on Lead with filter Stage = New.
3. Add a begin activity to the workflow.
4. Open CRM, create a Lead in the New stage.
5. Back in the campaign, click Generate Participants.
6. In the CRM pipeline, drag the Lead from New to Qualified.
7. Back in the campaign, click Generate Participants again.
8. Open the Participants smart button, click the participant for the moved Lead.
9. Click the cancelled activity in the workflow timeline.

=> The activity dialog shows "Error message: Record deleted" although the Lead still exists.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6251264)
opw-6251264

Forward-Port-Of: odoo/enterprise#118692

Currently, an error occurs when a user removes the payslip date.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and remove the `start` or `end` period.

**Error 1:**
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

**Error2:**
`AttributeError: 'bool' object has no attribute 'month'`

When a user removes the start or end date of a payslip, the system computes the Average Daily Wage. 
Based on the payslip dates, it finds the previous year's payslips [1]. If the start or end date is not set, 
it raises an error [2].
For the second error, when computing whether to include EOY pay, it compares the company's EOY 
pay date with the end date's month. If the end date is not set, accessing its month raises an error [3].

This commit ensures that when retrieving previous-year payslips, if the start or end date is not set, 
it returns an empty payslip recordset. It also ensures that when computing whether to include EOY 
pay, if the end date is not set, `include_eoy_pay` is set to `False`.

[1]: https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L124

[2]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L209-L215

[3]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L141

Forward-Port-Of: odoo/enterprise#123135
Forward-Port-Of: odoo/enterprise#120586

Issue
-----
When shipping internationally with Easypost, the currency on the commercial invoice does not always match the one of the sale order.

Steps to reproduce
-----
- Install Easypost
- Create a new pricelist using a different currency from the company
- Create a SO
	- Some product with a weight & HS code
	- Customer must be in another country from company (for commercial invoice)
	- Use the new pricelist
	- Add easypost delivery
- Confirm SO
- Validate linked picking

> Commercial invoice uses company currency instead of SO's

Cause
-----
The currency being sent to Easypost is retrieved from the package in

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L146

The package object is actually created by calling the carrier's `_get_packages_from_picking` method

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L266-L270

Solution
-----
We could be fixing this in `stock_delivery` by creating the package with the correct currency when calling `_get_packages_from_picking`. The problem with this approach is that this might negatively affect other carrier services, as discussed in https://github.com/odoo/odoo/pull/268224.

Instead, we can apply a band-aid fix to take the currency from the picking's sale in the `delivery_easypost` module, which is the only one where the problem was reported.

-----
Ticket:
opw-6224883

Forward-Port-Of: odoo/enterprise#123083

**Issue**:
Even when creation of new Serial Numbers for components is disabled
on the Manufacturing Operation Type, it is still possible to create
them from the shopfloor application.

**Steps to reproduce**:
- Enable "Lots & Serial Numbers", on the global settings
- Create two products, one tracked by unique serial number
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Select Manufacturing and disable "Create New Lots/Serial Numbers for Components"
- Create and confirm a MO using the tracked product as component
- Go to shopfloor
- Click the "+" button next to the component, then "New"
-> No error is raised when creating a serial number

**Cause**:
The `_check_create` constraint relies on `active_mo_id`:
https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19
However, the shopfloor does not pass this, in context:
https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199

As a result, the check is bypassed.

opw-6041241

Forward-Port-Of: odoo/enterprise#111408

### [FIX] knowledge: load comments on first load
There was an issue where comments are not displayed when opening an article
containing some.

How to reproduce:
- create a new article, write some text and add some comments.
- reload the page

Issue:
- comments are not displayed, but they are when switching back and forth to
  another article

Reason:
Owl2 -> Owl3 refactoring:
commit [1] replaced useRecordObserver by onWillUpdateProps, however the 2
are not equivalent, especially over the timing of the first call
(useRecordObserver callback is called during setup).

### [FIX] knowledge: batch vertical dimensions computation once
There was an issue where comments were not displayed at their correct position
(height/top) in "handler" mode.

How to reproduce:
- create an article with 3 comments over 5 lines, following a given pattern:
  - one comment on the first line
  - one comment on the second line
  - keep the third line empty
  - one comment across the 4th and 5th lines
- reload the page (issue 1)
- click successively on the 3 comments zones (issue 2)

Issue:
- issue 1: the comments on reload overlap each other while they should not
- issue 2: when clicking on the 3rd comment, the 1st and 2nd comments appear
  offset by an abnormal vertical distance (which should not exist)

Reason:
Owl2 -> Owl3 refactoring:
Commit [1] replaced reactive + batched callback with `useEffect` executing
that same batched callback, however `useEffect` is already batched starting from
the second call, effectively batching twice, which resulted in the wrong
dimensions being computed for knowledge comments in the comments_handler

[1]: https://github.com/odoo/enterprise/commit/ab1e2cad9a214a1303e13fdff0e8a62781ef56ee

task-6370985

Forward-Port-Of: odoo/enterprise#123339

When an employee's Income Stream Type is changed after a payslip has been created,
computing the sheet for payslip will raise a traceback.

Steps to reproduce the  error:
- Install ``l10n_au_hr_payroll_account`` module with demo data
- Switch to ``My Australian Company`` company
- Create a new payslip for ``Dennis Cactus`` Employee > Save
- Go to Employees > Open the ``Dennis Cactus`` employee >
  In Payroll tab, Income Stream Type: Other specified payments > Save
- Go back to payslip > click the compute sheet button

Traceback:
```py
KeyError: 'OSP'
```

https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L175-L178
The ``l10n_au_income_stream_type`` field on the payslip is a computed field that only depends on ``employee_id``.
As a result, changing the employee's Income Stream Type does not trigger a recomputation of the corresponding field on existing payslip.
So, when the ``payslip_ytd_totals`` field is computed, it uses the old value of ``l10n_au_income_stream_type`` field at [1], The resulting ``payslip_ytd_totals`` is then used to build the ``totals`` dictionary, and eventually, when the employee's current ``income_stream_type`` is used to access
``totals``, the mismatch key leads to the above traceback. https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll_account/models/hr_payslip.py#L75-L88

[1]: https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L269-L272

solution:

I added ``l10n_au_income_stream_type`` to ``add_to_compute()`` in ``compute_sheet()``.
This ensures that stale values of ``l10n_au_income_stream_type`` on
existing payslips are recomputed when the payslip sheet is computed.

sentry-7536819310

Forward-Port-Of: odoo/enterprise#123288
Forward-Port-Of: odoo/enterprise#120143

The Download PDF option of an article prints the page with the browser. On screen, the article body is inside .o_scroll_view_lg, which scrolls when the content is longer than the screen:

https://github.com/odoo/enterprise/blob/79f8defa04476e1b939dc8bb5449a775137aed62/knowledge/static/src/scss/knowledge_views.scss#L170-L177

The print stylesheet used to force overflow: visible on every div, so this container did not scroll when printing. It also hid every child of the body except the action manager, so the navbar and open dropdowns were left out of the print. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rewrote knowledge_print.scss to scope its rules to the Knowledge view and removed both rules. The scroll container now keeps its fixed height and its scrollbar when printing, so the scrollbar is drawn in the print preview and on every page of the PDF. The dropdown opened to reach Download PDF is printed on top of the article when it overlaps the page area, which happens when the browser is zoomed in.

Add overflow: visible to the print rule of knowledge_print.scss that already targets .o_scroll_view and .o_scroll_view_lg with position: static. That rule exists to undo the screen positioning of the scroll containers when printing, so the overflow reset belongs there. Its selector is also more specific than the screen one, so the value applies without !important, like position: static already does. Restore the rule that hides the body children other than the action manager, scoped to the Knowledge view like the rest of the file since the print stylesheet is now loaded on every page.

Before:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/44aa3366-3fc8-4382-8aa2-84625fa4b6d8" />

After:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/8b6eb2bc-37a3-4666-b871-0e6149c41fea" />

Steps to reproduce:
1. Open the Knowledge app and create an article
2. Paste enough text in the article to fill more than one PDF page
3. Zoom the browser to 200%
4. Click the three dots in the top right corner, then Download PDF
5. Check the print preview or the saved PDF

=> A scrollbar is drawn on the right edge of every page and the dropdown menu is printed on top of the article

Ticket [link](https://www.odoo.com/odoo/project.task/6279174)
opw-6279174

Forward-Port-Of: odoo/enterprise#120249

Issue
-----
When using Sendcloud batch deliveries, users get a traceback if the transfer is split into multiple packages.

Steps to reproduce
-----
- Setup Sendcloud
	- Enable batch delivery
- Create a delivery for 2 units of a product
	- Delivery method set to sendcloud
- Put each unit in a separate package
- Validate the delivery

> Traceback

Cause
-----
Bug introduced by #90302 (so only present in 19.3+).

When using the batch deliveries option, the packages are sent in a single list. This means that, in `_prepare_parcel`, when we iterate over the packages, `pkg` can be a list

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L462

This means that `pkg.name` will fail

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L481

Considering that a batch delivery uses the same reference number on all labels, we can pass `None` as a fallback to `_get_unique_order_number_reference` (it is an accepted value)

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L388-L393

-----
Ticket:
opw-6267928

Forward-Port-Of: odoo/enterprise#120206

The `body` field on `whatsapp.message` was defined with `related_sudo=False` with the intent of restricting access to messages from restricted records. However, this was never actually providing any security value because [`mail.message.fetch()`] was overriding it with `self.sudo()` till `v19.1`, meaning the body was always fetched as superuser regardless:
```py
    web_search_read() -> search_fetch()
    -> fields.py _compute_related()
    -> record[self.related_field.name]  # triggers fetch of mail.message.body
    -> models.py _fetch_field()
    -> mail_message.py fetch()
    -> self = self.sudo()  # sudo hack overrides related_sudo=False silently
```
In `v19.2`, the `fetch()` sudo hack was intentionally removed (see commit odoo/odoo@4727f12d274a0b2d7c455363d189565bd8fb2e7a) as access rights are now cached and can be checked without a performance penalty. This exposed the broken `related_sudo=False` which now causes an `AccessError` when trying to read the body of a `whatsapp.message` whose linked `mail.message` points to a document the current user cannot access (e.g. `purchase.order`).

Access control on `whatsapp.message` is already correctly enforced at the `ir.rule` level:
- Regular users can only see messages they created (`create_uid = user.id`)
- WA Admins can see all messages

We have upgrade requests failing on this issue: TBG-[2765]

[`mail.message.fetch()`]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/models/mail_message.py#L812-L819
[2765]: https://upgrade.odoo.com/odoo/tbg/2765?debug=1

Forward-Port-Of: odoo/enterprise#119867

When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning.

Steps to reproduce:
-------------------
* Install barcode and stock
* Enable packages in settings
* Open Inventory
* Create a product,
* Create a Package Type -> barcode PACKTYPE,
* Create a Package linked to this package type -> PACK,
* Add at least 2 unit of product to this package,
* Create a delivery for 2 unit of the product,

Open Barcode
* Operation > Delivery orders > your delivery
* Erase the destination package from the first line
* Scan PACK
( don't click on the green line)
* Scan PACKTYPE

**Actual behavior**
create a new package but does not link it to the new products

**Expected behavior**
create a new package and set it as destination package.

Observation:
-------------
When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected:
https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090

When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType```  
where we will obtains packagesIds checking that we have a source package:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132
and will send us to ```_putPackInPack```:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136

Where we will avoid the empty packageIds since we checked on the source package and not the destination package:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299
and will call ```action_put_in_pack``` from the packaging model:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306

In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made.

Which means that in our case, we created a package without linking it to anything.

Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line :
https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117
It will not show the new package in barcode


opw-5449729

Forward-Port-Of: odoo/enterprise#120335
Forward-Port-Of: odoo/enterprise#104876

Steps to Reproduce
---
- Create two different working schedules with different public holidays
- Assign employees to specific working schedules
- Set company default working schedule to a different schedule
- Login as employee with specific working schedule
- Navigate to Timesheets app -> My Timesheets
- Observe public holidays and personal time-off displayed in the timesheet grid

Issue
---
- The timesheet grid displays unavailable dates (public holidays, weekends) from the company's default working schedule instead of the employee's assigned working schedule.
- Personal time-off requests are not reflected as unavailable dates in the timesheet grid.

Current Behaviour
---
- Public holidays shown are always from the company's default working schedule, ignoring employee-specific working schedule assignments.
- Employee's approved time-off requests don't appear as unavailable in the timesheet.

Expected Behaviour
---
- Public holidays should display based on the employee's assigned working schedule, with company schedule as fallback only when no specific schedule is assigned.
- Employee's personal time-off requests should appear as unavailable dates.
- This should align with Time Off app behavior.

Fix
---
- Included employee-specific work interval calculation with personal time-off requests.
- Added support for contract-based calendar changes and calendar validity periods.
- Implemented proper fallback when valid intervals are not found.

task-4997080

Forward-Port-Of: odoo/enterprise#123331
Forward-Port-Of: odoo/enterprise#95458

**Problem:**
When a team restricts automatic closing to specific stages
(from_stage_ids), the closing-reminder email is still sent to every
inactive ticket in the team, including tickets in stages that are
never auto-closed.

**Steps to reproduce:**
1. On a helpdesk team, enable Automatic Closing with a reminder and set
   "In Stages" (from_stage_ids) to one specific stage
2. Leave a ticket inactive in a different, non-folded stage until it
   reaches the reminder threshold (auto_close_day - reminder_delay)

**Current behavior:**
The ticket gets a "your ticket will be closed soon" reminder even
though it is not in an auto-close stage and will never be closed.

**Expected behavior:**
Only tickets that would actually be auto-closed (those in
from_stage_ids) should receive the reminder.

**Cause of the issue:**
The reminder selection filters on auto_close_ticket_reminder and the
reminder date only; unlike the auto-close selection, it does not apply
the team's from_stage_ids condition.

**Fix:**
Reuse the same stage condition used to select tickets for closing when
selecting tickets for the reminder, so the reminded set stays
consistent with the set that will be auto-closed.

opw-6291237

Forward-Port-Of: odoo/enterprise#120732

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

Forward-Port-Of: odoo/enterprise#120590
Forward-Port-Of: odoo/enterprise#118937

The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set.

When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload.

unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records.

Steps to reproduce:
1. Open the Knowledge app
2. Create an article with two child articles
3. Add one of the two children to your favorites with the star icon
4. Open another article that is not under that parent
5. Fold the parent article in the sidebar, then refresh the page
6. Expand the parent article

=> only the favorited child is shown under the parent, the other child is missing

Ticket [link](https://www.odoo.com/odoo/project.task/6186466)
opw-6186466

Forward-Port-Of: odoo/enterprise#118804

### Steps to reproduce:

- In the settings enable: "Storage Locations" and "Consignment"
- Create a storable product and put 1 unit in stock with a set owner
- Go to the barcode app > Operations > Delivery Orders > New
- Scan your product and validate
#### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit.

### Cause of the issue:

The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407
However, the option also make sense for none tracked products.

### Note:

Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330
Setting the same owner on the new move line as on the quant we are going to reserve:
https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715

Additional subtelties appearing when prefilling for non tracked product:

1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually
relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants.

2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line:
https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387
> This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned.

opw-6050657

Forward-Port-Of: odoo/enterprise#122998
Forward-Port-Of: odoo/enterprise#115021

### Steps to reproduce

* Enable the Units of Measure setting and create a packaging UoM for a product (e.g. "Pack of 10").
* Create a customer delivery for that product and confirm it.
* Open the picking in the Barcode app, scan the product unit barcode once, then scan the packaging barcode once.
* Exit the barcode app via the back arrow (without validating).
* Re-open the picking and validate it.

**Expected**: `move.quantity` reads `11` (1 unit + 1 pack of 10).
**Observed**: `move.quantity` reads `2` (the raw count of move lines), while the detailed move lines still show 1 unit and 1 pack of 10.

### Cause

On exit, `BarcodePickingModel._onExit` aggregates `qty_done` and `reserved_uom_qty` across the move lines and forwards the totals to `stock.move.post_barcode_process` -> `_truncate_overreserved_moves`. The aggregation ignored each line's own UoM, so a line in a packaging UoM (e.g. pack of 10) was counted as `1` instead of being converted to the move's UoM. `_truncate_overreserved_moves` then saw the real `move.quantity` (11, correctly computed from the move lines) as exceeding what the user supposedly did (2) and forcibly wrote `move.quantity = 2`. The accompanying `_set_quantity` runs with `unreserve_unpicked_only=True` and therefore skips the picked lines, leaving the move lines intact but `move.quantity` stuck at the wrong value through the validation that follows.

### Fix

Convert each line's quantity to the move's UoM (using the cached `uom.factor`) before aggregating in `_onExit`. `product_uom` is added to `stock.move._get_fields_stock_barcode` so the move's UoM is available in the client-side cache.

### Why 19.0 only

In 18.0 and earlier, scanning a packaging multiplied the scanned quantity in the **product's** UoM (`_retrievePackagingData` returned `quantity = barcodeData.packaging.qty` with `uom = product.uom_id`), so the resulting move lines were all in the same UoM and the raw aggregation was correct. In 19.0 the packaging rework made the scan create a move line in the **packaging's** UoM with `quantity = 1`, which exposed the missing conversion in `_onExit`.

### Test

`test_scan_packaging_on_picking_with_mixed_uom` is extended with a 5th receipt that scans 1 unit + 1 pack of 6, exits via `button.o_exit`, re-opens the picking and validates. Without this fix the assertion `quantity == 7.0` fails (truncated to 2).

On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some.

### Steps to reproduce

- Install Appointments.
- Create a recurring appointment type available on a single weekday (say Monday), with a user or resource assigned and a date range spanning a few months.
- Set `Allow bookings at least` (the minimum booking delay) so that the current time plus the delay falls after this month's last Monday. Close to the end of a month, a day or two of delay is enough.
- Open the booking page: the first month shown is next month, because the delay skipped this month's last slot.
- Click the arrow to move forward one more month.

=> the reached month shows no slots, even though it has Monday availability.

### Cause

The calendar computes availability one month at a time. It builds a list of months, and the browser refers to each month by its position in that list (0, 1, 2, ...). Clicking the next arrow sends that position back to the server.

The server turns the position into a real month by adding it to a start month, which it computes as `now` plus the minimum booking delay. But the list shown to the visitor does not start there: it starts at the month of the first slot that can actually be booked.

These two are usually the same, so the position lines up. They stop matching when the delay moves the earliest bookable time past the last availability day of the current month. In the steps above, `now` plus the delay lands after the month's last Monday, so the first bookable slot is a Monday in the next month. The visitor's list then starts one month later than the server assumes, every position points one month too early, and the server computes availability for a month the visitor is not looking at. The reached month comes back empty.

### Fix

Count the visitor's month position from the same first bookable slot the list starts from, instead of from `now` plus the delay. The navigation offset is passed to the slot computation and resolved against that slot, so the filled month always matches the month the visitor sees.

opw-6353569