When an attachment has neither `store_fname` nor `db_datas`, the computed `raw` field was being assigned `False`.

This caused crashes in flows expecting binary content, where `binary_to_image()` ultimately passes the value to `io.BytesIO()`, which requires bytes-like data.

Traceback:
```python
Traceback (most recent call last):
   File "/tmp/tmpufuj48vj/migrations/base/tests/test_mock_crawl.py", line 344,
 in crawl_menu self.mock_action(action_vals)
   File "/tmp/tmpufuj48vj/migrations/base/tests/test_mock_crawl.py", line 357,
 in mock_action return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmpufuj48vj/migrations/base/tests/test_mock_crawl.py", line 517,
 in mock_act_window mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpufuj48vj/migrations/base/tests/test_mock_crawl.py", line 550,
 in mock_view_form [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2734, in read
    self._origin.fetch(fields)
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3065, in fetch
    fetched.mapped(field_name)
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5477, in mapped
    return [getter(record) for record in records]
            ^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1793, in
 __get__ self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1964,
 in compute_value records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-19.2/addons/mail/models/mail_thread.py",
 line 495, in _compute_field_value return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4269,
 in _compute_field_value determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 82,
 in determine return needle(*args)
           ^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/social_instagram/models/
social_post_template.py", line 57, in _compute_instagram_preview
    faulty_images, error_code = post._get_instagram_image_error()
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/enterprise/saas-19.2/social_instagram/models/
social_post_template.py", line 108, in _get_instagram_image_error
    image = binary_to_image(jpeg_image.with_context(bin_size=False).raw)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/tools/image.py", line 428,
 in binary_to_image return Image.open(io.BytesIO(source))
                      ^^^^^^^^^^^^^^^^^^
 TypeError: a bytes-like object is required, not 'bool'
```
To prevent this, fallback to an empty bytes object (`b''`) when `db_datas` is falsy during `_compute_raw`.

[here]: https://github.com/odoo/enterprise/blob/saas-19.2/social_instagram/models/social_post_template.py#L108

upg-4247928
opw-6181262

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

***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

When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines.

Steps to reproduce:
-------------------
* Install timesheet_grid and project_mrp_account
* Create product A, storable
* Create product B with a cost of 20 and also storable
* Update the available quantity of product B
* Create a BoM for product A, it should only require one product B
* Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver
* Create a first MO for 1 product A and produce it
* Create a second MO for 1 prodcuct A but just confirm it
* Login as Marc Demo and try to scrap the component of the second MO
> Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95

opw-5954989

Forward-Port-Of: odoo/odoo#262104
Forward-Port-Of: odoo/odoo#255824

Currently an exception is generated when the user tries to save the report XML as follows:

- Install sale_management and web_studio
- Go to Sales > Enable Studio Mode > Open Reports
- Click New > Select `Blank` Report
- Click `EDIT RESOURCES` and replace all XML with below (Remove `lock-id`)
```
<t t-name="web.basic_layout">
        <t t-call="web.html_container">
            <t t-if="not o" t-set="o" t-value="doc"/>
            <div class="article" t-att-data-oe-model="o and o._name" t-att-data-oe-id="o and o.id" t-att-data-oe-lang="o and o.env.context.get('lang')">
                <!-- Your report content -->
            </div>
        </t>
    </t>
```

Error: `KeyError: None`

This issue arises because users removed `lock-id` (identified nodes) attributes from elements, making them untraceable. As a result, fetching the `DIFF_ATTRIBUTE` (key for getting identified) nodes from the modified XML (new_tree) returns `None`, which causes an error when attempting to access the corresponding node in `map_id_to_node_old` (see see code at [1]).

This commit fixes the issue by preventing access to `map_id_to_node_old` when the `key (new_tree.get(DIFF_ATTRIBUTE))` is `None`. In this case, no changes are applied, and the original XML is returned since no identifiable attribute is available in new XML tree.

sentry-7349653271

- 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 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

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

Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.

Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.

Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.

Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
  company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.

opw-5462037

Forward-Port-Of: odoo/enterprise#117376
Forward-Port-Of: odoo/enterprise#115475

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#262321

Steps to reproduce:-
- Navigate to Time off Dashboard calendar view.
- Create a leave. First approve it then refuse it.
- Now on the same day create a leave and approve it.
- Now re-approve the previously refused leave from step 2.
- System will let user to create 2 leave of same types on same day!

Cause:-
In `_compute_dashboard_warning_message`, refused/cancelled leaves were
excluded from warning computation. When approving a refused request,
the warning message was not set, allowing the constraint check to pass
even when conflicting approved requests existed for the same period.

Fix:-
1. Refactored `_compute_dashboard_warning_message` to only compute
   warnings for active leaves (non-refused/cancelled) while still
   detecting conflicts with already approved requests
2. Updated `_check_date` constraint to skip validation for refused/
   cancelled leaves, but enforce it when state changes to validate
3. Added 'state' to constraint triggers to ensure validation runs
   when approving previously refused requests

task-[6181717](https://www.odoo.com/odoo/project/1251/tasks/6181717)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265038
Forward-Port-Of: odoo/odoo#262703

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