`#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:
	- Install Employee
	- Create a 2-week working schedule and set it as the company default
	- Try to create a new working schedule
	- Notice when you click save a ValidationErroe arise


## Cause:
Two parts where causing this. First when creating a new calendar and
we try to fetch default attendances we don't set the sequence in the
newly created attendances

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L735-L749

so it will get the default value which is 10 so when calling onchange for 
the attendance_ids_1st_week and attendance_ids_2nd_week each attendance
will be set to the odd_week_seq

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L184-L200

which will then make this condition fail

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L615-L616

Second part was related to the `two_weeks_calendar` when saving,
its value won't be passed to the vals_list in `web_save()` as when
we read the values to be changed we ignore readonly fields and since
two_weeks_calendar was used in invisible condition but isn't defined
in a separate `<field>` the view create a tag for it

`
<field name='two_weeks_calendar' invisible='True' readonly='True' data-used-by='invisible='flexible_hours or not two_weeks_calendar' (page,working_hours)' on_change='1'/>
`
This tag would be readonly by default so when the ArchParser
gets each field's info it puts `two_weeks_calendar` as a readonly
field and ignore it in the creation values

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/web/static/src/views/fields/field.js#L276-L279

which then fails this condition and pass all the 2 weeks attendances in the else condition

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L134-L138

After fixing this another bug was found where if you saved the calendar
the attendances will disappear. This was happening when we create the
resource.calendar.attendance records it will call the inverse method
of the attendance_ids_1st_week and attendance_ids_2nd_week where they are
still not computed so it will set attendance_ids to empty

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L152-L156

so after when computing the two weeks attendance it will be empty
as well and it will disappear.

Last bug was if after creating this you tried to switch the calendar
type it will call the same validation error mentioned earlier. As when
calling _get_default_attendance_ids it will try to create attendances
from the company's default working schedule which will have a conflict
since the company's schedule is 2-weeks schedule and we are switching
our schedule to 1-week schedule so we are gonna have attendances for 2-weeks
in 1-week schedule so it will fail the same condition

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L615-L616

## Fix:
To fix those issues we needed to set the sequence values when copying
the data of the company's schedule when computing the default values. 

Also we need to skip the inverse method when we are still upon creating the records
and to do so we are passing a context in the create method to skip
the inverse.

Last we need to check for the difference between the schedule type and the
company's schedule when fetching the default attendances.

opw-6374237

Forward-Port-Of: odoo/odoo#281302
Forward-Port-Of: odoo/odoo#279182

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

Steps to reproduce the bug:
- Install repair and accounting
- Create a user and grant them only Inventory / User access
- Log in as that user and open any Repair Order

Problem:
Opening the repair order raised:
"Failed to read field repair.order.invoice_ids
You are not allowed to access 'Journal Entry' (account.move) records."

`invoice_count` and `can_create_sale_or_invoice` are computed fields that read `invoice_ids`, a One2many to `account.move` Reading a One2many always queries the comodel, so this triggers an ACL check on `account.move` for the current user, even though the repair order has no invoice and the field is only used to display a count/boolean. A user with `stock.group_stock_user` but no accounting/sales rights has no access to `account.move`, so simply opening the form crashes.

Solution:
Read `invoice_ids` with `sudo()` inside `_compute_invoice_count` and `_compute_can_create_sale_or_invoice`, since only a derived count/boolean is exposed to the user, not the invoice records themselves.

opw-6447829

Forward-Port-Of: odoo/odoo#281692

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/464be42c69 [REL] 19.3.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/978c6f5dfc [FIX] functions: omit functions from the squisher [Task: 6452075](https://www.odoo.com/odoo/2328/tasks/6452075)
https://github.com/odoo/o-spreadsheet/commit/47b7938d2b [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