Issue before this commit:
=========================
When creating a product by adding a barcode using the Barcode Lookup service,
the product image was fetched properly but was not displayed in the UI.

Steps to Reproduce:
=========================
- Install the stock module.
- Enable the Stock Barcode Database.
- Add a valid API key for the Barcode Database.
- Create a product by adding a barcode available in the Barcode Lookup API.
- Notice that the product image is not displayed.

Cause of the issue:
=========================
This issue was introduced by this [PR](https://github.com/odoo/odoo/pull/244421), 
which improved the behaviour of **fields.Binary**. As a result, the image returned by 
the Barcode Lookup API was not converted to the expected binary format, preventing
it from being displayed in the UI.

With This Commit:
=========================
With this commit, convert the fetched image to the expected binary format 
before assigning it to the product, ensuring that it is displayed correctly in the UI.

opw-6434478

Forward-Port-Of: odoo/enterprise#126314

Steps to reproduce:
===================
1. Create a subscription product, allow one-time sale, sale price 5
2. Add a recurring price 10/month
3. On the pricelist, add an advanced rule: -10% for the monthly plan
4. Open the shop page and look at the product tile

Cause:
=======
On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`.

In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price

With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price.

Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan.
=> Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9).

Solution:
=========
The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`.

opw-6307398

Forward-Port-Of: odoo/enterprise#124815
Forward-Port-Of: odoo/enterprise#120872

**Issue:**
In the website builder, when entering "Edit" mode through "Edit" button, the main navbar is hidden.
An animation is moving the navbar upwards and a "d-none" class is added to it after a delay of 200ms to avoid it disappearing suddenly.
It is displayed again after saving the changes by removing the "d-none" class.
However, when entering "Edit" mode and leaving it quickly, it is possible that the code hiding the navbar is executed after the code displaying it again because of the 200ms setTimeout().

The issue is not reproducible in the UI directly, but the `test_32_website_background_colorpicker` tour is often failing with the following error:
```
FAILED: [53/65] Tour website_page_options → Step <b>Click Edit</b> to start designing your homepage. (trigger: body:has(:iframe body[is-ready=true]) .o_menu_systray .o_menu_systray_item.o_edit_website_container button).
Element (body:has(:iframe body[is-ready=true]) .o_menu_systray .o_menu_systray_item.o_edit_website_container button) has not been found.
TIMEOUT step failed to complete within 10000 ms.
```

During the tour several clicks on "Save" and "Edit" are executed, leading to the navbar being unavailable when trying to click on "Edit".

runbot-243712




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

Forward-Port-Of: odoo/odoo#278645

**Steps to Reproduce:**

1. Send a message to Marc demo with Mitchell admin or vice-versa, read the message from reciever's side.
2. Click on seen-by indicator from sender's side, make sure the dialog appears and then Press `'ESC'`.
3. Chat window closes whereas the dialog should have closed.

Since #169737, pressing 'esc' on the seen-by dialog closes the chat window instead of the dialog.

The chat window's root element has a keydown handler that closes the window on `'escape'`, and catches focus by default whenever something non-focusable is clicked inside it (e.g. the seen-by indicator). The seen-by dialog's content had no focusable element, so it never grabbed focus for itself, leaving focus on the chat window. Pressing 'escape' therefore closed the chat window instead of the dialog.

This commit fixes the issue by adding tabindex on the template, letting the dialog grab focus like other dialogs/popovers already do, so `'escape'` is handled by the dialog first.

task-4895004

Forward-Port-Of: odoo/odoo#281656
Forward-Port-Of: odoo/odoo#278847

Steps to Reproduce:
------------------------
- Install the Point of Sale module & create an order with a customer (partner).
- Scan the QR code on the receipt to retrieve the invoice.

Issue:
-------
When clicking `Get My Invoice`, the invoice was not being generated.

Cause:
---------
- The correct partner was not being set. POS customer scanning the QR code is not logged into Odoo, so no partner is associated with the request. We were incorrectly using the logged-in user’s partner, which resulted in an empty partner and therefore an empty VAT value.
- The customer's country was also incorrect because the partner’s country was fetched but then overwritten by the order’s country due to improper value assignment.

Fix:
----
- In most POS scenarios, the customer associated with the order is the one requesting the invoice. Therefore, if no logged-in user is found, we now correctly use the order’s partner to retrieve VAT and other required information.
- The partner's country was corrected by ensuring the values are assigned in the proper order and no longer overridden incorrectly.

task: 5406951

Forward-Port-Of: odoo/odoo#281615
Forward-Port-Of: odoo/odoo#239811

`#right-elements` (tax totals block) is floated (`float-end`). Per CSS spec, an `auto` margin on a floated element always resolves to 0, so the `ms-auto` class added by 9767e8f5c1da5a9c9e38472ad576ffa3c4e32075 is a no-op, leaving no gutter before adjacent content such as the legal notes paragraph.

Partial revert of 9767e8f5c1da5a9c9e38472ad576ffa3c4e32075

Steps to reproduce:
-------------------
* On a tax, set a multi-line paragraph in Legal Notes (Advanced Options tab)
* Apply it on an invoice line and print/preview the invoice PDF
> Observation: the legal notes text touches/overlaps the tax totals
table, with no spacing.

Why the fix:
------------
`ms-5` gives `#right-elements` a real left margin, restoring the spacing lost when `ms-auto` (a no-op on floats) replaced it.

BEFORE:
<img width="596" height="753" alt="Screenshot 2026-08-05 at 10 52 00" src="https://github.com/user-attachments/assets/c596d6e9-4b61-434c-9b38-3ff0797e7fa7" />
AFTER:
<img width="494" height="596" alt="Screenshot 2026-08-05 at 10 51 44" src="https://github.com/user-attachments/assets/f9a1792d-22c2-4586-9a75-53c4695f17e4" />


opw-6384085

Forward-Port-Of: odoo/odoo#280654

l10n_vn_pos_symbol carries groups='base.group_system,point_of_sale.group_pos_manager', but _prepare_invoice_vals reads it while an ORDINARY salesperson closes an order: _process_saved_order calls _generate_pos_order_invoice as the acting user, with no sudo anywhere on the way. So on a Vietnamese POS with auto-send to SInvoice enabled, a user in point_of_sale.group_pos_user alone hit

  Access Denied by ACLs for operation: read, model: pos.config, fields: l10n_vn_pos_symbol

and the order never finished syncing - the receipt screen's Done button stayed disabled and the checkout dead-ended.

This is reachable from the module's own test suite, which is what makes it more than theoretical: point_of_sale's start_pos_tour logs in as `pos_user` (group_pos_user, NOT group_pos_manager - that is `pos_admin`), so test_l10n_vn_edi_pos_refund_reason_tour exercises exactly the unprivileged path.

Reading the config as sudo is the right resolution rather than widening the field's groups: the salesperson is never shown the symbol or allowed to change it, it is only stamped onto the invoice their own sale produces, which is what a per-POS configuration field is for. Both symbols are read through the same sudo recordset so the company-level fallback keeps working identically.

Reproduced and verified on v18_full (5-repo addons path):
  before - FAILED: [13/36] Tour L10nVnEdiPosRefundReasonTour -> "go to next screen from
           receipt"; 1 failed, 0 error(s) of 1 tests
  after  - tour succeeded for both tours in the class; 0 failed, 0 error(s) of 2 tests,
           and no ACL line left in the log




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

Forward-Port-Of: odoo/odoo#281621
Forward-Port-Of: odoo/odoo#281119

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

Before this commit, `visitor leaving ends the livechat conversation` failed about once in a hundred runs:

    Failed to find 1 of "span" with text "This livechat conversation
    has ended." (Timeout of 10 seconds). Found 0 instead.

This happens because the test only waits for the `channels_as_member` request to reach the server, from the `onRpc` callback that runs before the route is served. The answer holds `livechat_end_dt` as `false` and lands right after the `mail.record/insert` of the visitor leaving, so the date goes back to `false` and the conversation still looks open.

One solution could have been to use `waitStoreFetch`, but its step comes from that same callback, and the helper returns six microtasks before the answer is inserted, on a hundred runs out of a hundred.

This commit fixes the issue by waiting for the messaging menu to list a plain channel, which arrives with the `channels_as_member` answer only.

https://runbot.odoo.com/odoo/error/945672

Forward-Port-Of: odoo/odoo#281582
Forward-Port-Of: odoo/odoo#281489

[FIX] hr_attendance: restricting visibility-monthly hours smart button

Bug reproduction:

    1 - v19 and later on
    2 - Even though you don't have a group attendance_user or attendance_manager and you are not the attendance manager of some employee
    3 - You can see the smart button "monthly hours" in the employee form view

Bug cause:

    1 - If the user is attendance officer (which means at least attendance manager of 1 employee) the smart button does always appear.

Bug solution:

    1 - I declared new non-stored show_monthly_hours_button field to determine whether should I show the smart button or not.
    2 - I used invisible in employee and employee.public views to hide the button when there is no authorization.

task - 6387595

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

Forward-Port-Of: odoo/odoo#276295

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/65642fe89b [REL] 19.4.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3005372b04 [FIX] functions: omit functions from the squisher [Task: 6452075](https://www.odoo.com/odoo/2328/tasks/6452075)
https://github.com/odoo/o-spreadsheet/commit/7555012afa [FIX] Session: deactivate command squisher [Task: 6462247](https://www.odoo.com/odoo/2328/tasks/6462247)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

*: website_event_exhibitor

bug:
`_get_srcset` defaulted `max_size` to '1920' when no `preview_image`
option was given, causing srcset entries to be generated for image sizes
larger than the rendered field. It also did not check whether each
candidate field existed on the record, leading to missing or broken
srcset entries.

steps:
- Add an event with a sponsor
- add a logo to the sponsor
- go on the website → events → the event you added
- The sponsor have no logo

fix:
Fall back to `field_name` to cap the srcset at the size of the rendered
field when `preview_image` is not set. Skip candidate fields not present
on the record.

reason:
When rendering e.g. `image_512`, the srcset should not include larger
sizes. Checking field existence avoids accessing fields the record does
not carry.

This bug already had fixes [1] and [2], this PR fixes the problem
globally and reverts the old fixes.

Bug introduced by https://github.com/odoo/odoo/commit/36e680feca4884940e020119de6a13cd7f927516.

[1]: https://github.com/odoo/odoo/commit/6bd2de2f3dbdd1a54b85db1e5215ecbbe9049113
[2]: https://github.com/odoo/odoo/commit/c21602d98028ab135a997816eb2601bdbe6c0a61

task-6123503

Forward-Port-Of: odoo/odoo#270149

Steps to reproduce:

0. Create an employee with a fixed working schedule and an overtime ruleset, then enable Absence Management in attendances
1. Go to Attendances and make sure that the employee has no attendances recorded for the previous working day
2. Run the "Attendance: Detect Absences for employees" scheduled action
3. Observe the absence attendance created on the previous working day, along with the amount of overtime hours calculated
4. Create an attendance on the day that the absence was recorded
5. Observe that the overtime hours on the absence attendance are not updated 5a. If a full day attendance is recorded on that day, the overtime hours on the absence attendance should change to 0, since we've now recorded hours worked for the day

When an absence attendance is created from the Absence Management feature, overtime hours are calculated to represent the time the employee was unjustifiably absent on a given day. If an attendance is later created on the day the absence was recorded, the overtime hours should update to reflect the hours the employee actually worked. Changes were introduced in [this PR](https://github.com/odoo/odoo/pull/272447) that broke this functionality due to the use of `pytz`, which incorrectly calculated timezone offsets. This caused absence attendances to not be picked up by `_get_overtimes_to_update_domain()`, and overtime was not correctly updated. This commit ensures that we get proper time calculations with respect to the employees timezone.

[opw-6380343](https://www.odoo.com/odoo/my-tasks/6380343?debug=assets)

Forward-Port-Of: odoo/odoo#281844
Forward-Port-Of: odoo/odoo#279556

Before this commit, some layouts had the customer address on the right
(light, boxed, bold, striped) and some had it on the left (bubble, wave,
folder). For the latter, when an information_block with the address existed,
it would be inserted before the address pushing it further right. This was
inconsistent since the address position should not depend on whether an
information_block is present or not.

The customer address must stay in a fixed place to match the transparent
window of the envelope when sending a physical letter by snailmail.

This commit fixes this issue by ensuring that in all cases the customer
address position stays fixed regardless of the presence or absence of
the information_block and regardless of the layout used for the letter.

It also fixes the addresses displayed on the sale order report:
1) If invoicing address = partner address != shipping address
or invoicing address != partner address = shipping address
then the three addresses would be printed, even though 2 addresses
are identical.
2) The shipping address and the invoicing address are now printed
horizontally rather than vertically to get rid of the resulting large
blank block under the partner address in that case.

backport of: https://github.com/odoo/odoo/pull/276622

task-6340467

Forward-Port-Of: odoo/odoo#281937
Forward-Port-Of: odoo/odoo#273640