Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

Forward-Port-Of: odoo/enterprise#116914
Forward-Port-Of: odoo/enterprise#112522

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264759
Forward-Port-Of: odoo/odoo#241827

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#264518
Forward-Port-Of: odoo/odoo#260566

**Steps to Reproduce:**
- Start a new meeting (Host Tab).
- Duplicate the tab or open the same meeting URL in another tab (remote tab).
- In the remote tab, open the call menu (dropdown).
- From the host tab, disconnect/end the call.
- Crashes on Remote Tab.

**Current behavior before PR:**
Before this PR, duplicating a meeting tab could leave the remote tab 
with a stale call action dropdown after the host ended the call. Since 
some action properties and handlers still assumed that selfSession 
and channel were always available, interacting with the dropdown could 
crash with errors.

**Desired behavior after PR is merged:**
After this PR, call action labels/classes defensively tolerate 
missing selfSession or channel references, and stale click handlers 
gracefully no-op when the call disappears mid-interaction. This prevents
remote tab crashes during call teardown while preserving the existing UI 
behavior.

task-[6191740](https://www.odoo.com/odoo/project/1519/tasks/6191740)

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

Forward-Port-Of: odoo/odoo#264989

**Problem:**
When opening a PDF attachment preview in v19+, the print button disappeared. As a result, the Print button is not accessible from the main toolbar.

In v18 the buttons remained permanently visible.

**Steps to reproduce:**
- Open any record that has a PDF attachment in the chatter.
- Click the PDF attachment to open the preview popup.
- Observe toolbar buttons disappeared.

**Cause:**
commit responsible for this: https://github.com/odoo/odoo/commit/b7889d007f72c7e7f9f22318a9968338cde0ddb3 It was removed to prevent some bugs with some android/smartdevice and some old browsers

`file_viewer.js` passes `hidePrint: true` to `hidePDFJSButtons()`. This was originally added alongside the mobile guard (`isMobileOS()`), but the `isMobileOS()` guard in `hidePDFJSButtons` already handles mobile, so the explicit `hidePrint: true` in `file_viewer.js` was redundantly hiding Print on desktop too. https://github.com/odoo/odoo/blob/654a1caafc2ab7b2841c372910b2e81dc6e9c035/addons/web/static/src/core/file_viewer/file_viewer.js#L60-L71 https://github.com/odoo/odoo/blob/654a1caafc2ab7b2841c372910b2e81dc6e9c035/addons/web/static/src/core/utils/pdfjs.js#L35-L37

**Fix:**
- Remove `hidePrint: true` from `file_viewer.js` since mobile is already covered by the `isMobileOS()` check inside `hidePDFJSButtons()`.

opw-6216534

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

Forward-Port-Of: odoo/odoo#264739

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

Steps to see the issue:
- Add a shape to an image
- Remove it

=> Image element in the DOM still has some data related to the shape.
This commits adds a shared method to `ImageShapeOptionPlugin` to clean
shape-related data when we apply a shape, or remove it, the method
mirrors the behavior we had before the [html builder refactoring].

Also, commit [1] fixed the issue when the builder transfered shape or
hover related data to incompatible images, when replacing an image with
a shape/hover on it. However if these data attributes had already been
saved prior to that commit, it would stay there indefinitely. The same
could happen with hover effects attributes. Therefore, we add a
resource that we call before saving data to clean any stale image data.

Example of a CORS protected image: [2]

[1]: https://github.com/odoo-dev/odoo/commit/137a6d7e59e1d788745c3b796a14839e52a8c5bc
[2]: https://tinyjpg.com/images/social/website.jpg

[html builder refactoring]: github.com/odoo/odoo/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5172640

Forward-Port-Of: odoo/odoo#263662
Forward-Port-Of: odoo/odoo#259226

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

Steps to Reproduce:
---
1. Create a new project.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing the template conversion should properly restore the original project's
documents folder to active state and clean up the template's documents folder,
allowing template conversion again without document folder conflicts.

Fix:
---
- Archive original project's documents folder during template creation to
prevent mixed active/inactive states during copy operations
- Implement callback system to properly unarchive original project's
documents folder during undo

task-4916027

Forward-Port-Of: odoo/odoo#264429
Forward-Port-Of: odoo/odoo#223152

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

***Steps to reproduce*:**

- Install `l10n_co_reports` module.
- Create 2 vendor bills with taxes `0% EXEMPT` and `0.966% RteICA`.
- Navigate to Reports -> Colombian Statements -> Certificado de Retención en ICA
- Generate the PDF report.

***Observed behavior*:**

- An error is raised while generating the PDF: 
`AttributeError: 'AccountReportColumnData' object has no attribute 'get'`

***Cause*:**

After commit [1](https://github.com/odoo-dev/enterprise/commit/b92dc397bef029472a40223f51b611cdf5b631dc#diff-e97f74c63a6257470e69eb8122c12d0ce4afa5bc6013176bb69e702849575123) all report lines, columns, and annotations were converted
from dictionaries to custom objects (e.g., AccountReportColumnData). However,
the function `_get_report_values` still uses .get() to access values, which is only valid 
for dictionaries. Calling .get() on these objects raises an error.

***Fix*:**

- Replace the `get()` method usage with `column.name` format to access 
  values from `AccountReportColumnData ' properly.
- This ensures compatibility with the new structured column data format introduced in v19.2.

opw-6205984

Forward-Port-Of: odoo/enterprise#116902

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

Forward-Port-Of: odoo/odoo#264848
Forward-Port-Of: odoo/odoo#262321

Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45

Steps to reproduce:
- Create a new database with only the Purchase module installed
- Enable the "Units of Measure & Packagings" option
- Create a storable product "P1" with the following vendor pricelist:
  - Vendor: Azure Interior (1 pack of 6 for $10)
- Create a purchase order:
  - Vendor: Azure Interior
  - Quantity: 3 packs of 6 of P1
- Confirm the PO
- Click the Receive button (available without the Stock module since v19.1)

Problem:
1:/
Expected behavior: qty_received = 3 (in purchase UoM: packs of 6)
Actual behavior:   qty_received = 18 (product UoM: units)

`product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6.

2:/
The parameter `invalid_targets` was not properly passed to the
translation function in the error message, causing a traceback
when trying to receive a PO in an invalid state.

opw-6080527

Forward-Port-Of: odoo/odoo#261630
Forward-Port-Of: odoo/odoo#260163

**Issue**
While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone.

**Steps to reproduce**
- Set the user timezone to UTC+1
- Create a storable product with:
  - quantity: 10 (created today)
  - unit cost: 5
  - valuation method: AVCO
- Go to Accounting > Review > Inventory > Inventory Valuation
- Select today's date
- Click on "Ending Stock"

-> The total value and quantity in stock are 0 instead of respectively 50 and 10.

**Cause**
When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation:
- 12/04 00:00 (user timezone) -> 11/04 23:00 UTC
- Converted to 23:59 UTC -> 12/04 00:59 in user timezone

As a consequence, most of the quantities created on 12/04 are excluded from the valuation.

This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153

This inconsistency leads to incorrect quantities and valuation results.

opw-5491743

Forward-Port-Of: odoo/odoo#255230
Forward-Port-Of: odoo/odoo#246163

There is no need to do a query to get a random foreign state. This search can be performed many times during imports.

While the query is generally not reading a lot of data, it is still doing a seq scan because of the ORDER BY, while the query can be avoided completely.

```sql
EXPLAIN ANALYZE
  SELECT "res_country_state"."id"
    FROM "res_country_state"
   WHERE "res_country_state"."code" NOT IN ('IN')
ORDER BY "res_country_state"."code", "res_country_state"."id"
   LIMIT 1;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=84.93..84.94 rows=1 width=8) (actual time=0.450..0.450 rows=1 loops=1)
   ->  Sort  (cost=84.93..90.49 rows=2224 width=8) (actual time=0.449..0.449 rows=1 loops=1)
         Sort Key: code, id
         Sort Method: top-N heapsort  Memory: 25kB
         ->  Seq Scan on res_country_state  (cost=0.00..73.81 rows=2224 width=8) (actual time=0.012..0.281 rows=2223 loops=1)
               Filter: ((code)::text <> 'IN'::text)
               Rows Removed by Filter: 2
 Planning Time: 0.075 ms
 Execution Time: 0.462 ms
```

This can be worse if when the table is not in the buffer.

Forward-Port-Of: odoo/odoo#265007