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

When importing a SODA XML file, users without the Analytic Accounting
group encounter an access rights error even if Analytic Accounting is not
enabled.

This occurs because the import wizard reads the `analytic_account_id` field
on the `soda.analytic.mapping` model to build an internal dictionary of
departments. Because this field is restricted to the Analytic Accounting
group, the evaluation of this field crashes the import for users even when
the Analytic Accounting feature is disabled.

This commit resolves the issue by using `.sudo()` on the analytic mapping
recordset to bypass the field-level group restriction.

**Steps to reproduce:**

- Log in as Mitchell Admin, change company to “My Belgian Company”
- Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Extra Rights > ensure “Analytic Accounting” is unchecked
   - Also ensure Mitchell Admin is not part of the “Analytic Accounting” group
- Accounting Dashboard > remove “Favorites” from filter > drag & drop a SODA XML file to “Miscellaneous Operations” > save > observe Access Error


**Current behavior before PR:**

- Users who don't belong to the Analytic Accounting group encounter an access error when attempting to import SODA XML files, even when the Analytic Accounting feature isn't enabled

**Desired behavior after PR is merged:**

- Those users no longer receive an access error

opw-6376039

Forward-Port-Of: odoo/enterprise#127867

Steps to reproduce:
--------------------------
1. Install helpdesk_planning_field_service_sale_timesheet and website with demo data.
2. Open a helpdesk team (e.g., Customer Care) and enable field service planning.
3. Create a new ticket in Customer Care, plan two interventions, and mark them as completed.
4. Click the cog menu of the helpdesk ticket and click Preview.

Issue:
-------
The "Field service" button is not visible.

Cause:
-------
Earlier, portal card visibility and existence were controlled directly in the QWeb template. After the portal refactoring, their visibility and existence are now managed by `portal.entry` records.

As a result, the field service entry is incorrectly considered unavailable, causing the test to fail on runbot.
Related build: https://runbot.odoo.com/runbot/build/123497806

Fix:
------
Determine the visibility of the "Field service" portal entry using the corresponding `portal.entry` record.
(Similar https://github.com/odoo-dev/odoo/commit/84ccbded9f4f1f00359b2eef59bce9527368fb05)

Related pr: https://github.com/odoo/enterprise/pull/129227

opw-6481737

**Problem:**
Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more, so closing one of them never produces the next occurrence.

**Steps to reproduce:**
1. Create a project with "Recurring Tasks" enabled
2. Create a task, tick "Recurrent" and mark it as done
3. Repeat on each generated occurrence until 3 or 4 tasks exist
4. Delete the last generated task
5. Open one of the tasks left in the suite

**Current behavior:**
The remaining tasks still show "Recurrent" ticked, but marking one as done creates no new occurrence and the recurring tasks smart button is empty.

**Expected behavior:**
Ending the recurrence should turn the "Recurrent" option off on every task that was part of it.

**Cause of the issue:**
`unlink` deletes the `project.task.recurrence` when the last task of the suite is removed, and `recurrence_id` is set to NULL on the other tasks by the database. Nothing resets their `recurring_task` boolean, so it stays `True` with no recurrence behind it. The two other places that end a recurrence, `write` and `action_unlink_recurrence`, already clear the flag on the whole suite.

**Fix:**
Aligning `unlink` with those two paths keeps a single meaning for `recurring_task`: it is only ticked while a recurrence actually exists. The suite has to be read before the recurrence is deleted, since the one2many is empty afterwards, and the tasks of the batch being deleted are left out so that no write lands on records that are about to disappear.

opw-6425292

Forward-Port-Of: odoo/odoo#282535

In Gantt views, for a given focus date, the appropriate time interval is
displayed by finding its start and end date, based on the scale.

For example, if I focus on 18 may 2026 with a month scale, then the
whole month of may is displayed.

The behaviour was as expected in standard code, because all
localisations agree on the beginning of the available scales (day,
month, year).

In custom code, however, some customer requires to see the gantt charts
with a weekly scale. The differences in start of the week based on the
localisations and the inconsistencies of use of localStartOf breaks the
view.

For example, if the localization has the start of the week on a sunday,
and a task on the first column starts on a sunday as well, it will get
assigned to column before (because it considers sunday as the last day
of the previous week). The column before the first column does not
exist, so one empty column is created to put the task in it.

This commit fixes these inconsistencies so that GanttRenderer behaves as
expected with weekly scales, without changing the standard behaviour.

Tests are written to check both that the task is assigned to the proper
localized week (starting on Sunday) and column (1, not 0).

Forward-Port-Of: odoo/enterprise#129249
Forward-Port-Of: odoo/enterprise#118625

Steps to reproduce:
- Enable presets on a restaurant PoS and tick "Amount of Guests" on the preset used for tables
- On device A, open a table and enter the number of guests
- On device B, open the same table

Issue:
Device B pops the guest count numpad again, even though the guest count was already entered on device A.

Cause:
ensureGuestCustomerCount guarded the popup on order.uiState.guestSetted. uiState is only serialized to IndexedDB (SERIALIZED_UI_STATE_PROP, used by serializeForIndexedDB); it is never sent to the server, so the flag is local to one browser and a second device always considers the guest count as not yet asked.

customer_count is synced and could carry that information, but PosStore createNewOrder pre-filled it with the table seats, so it was never 0 for a table order and could not tell "not asked" from "answered".

Fix:
Stop storing the seats default on the record and expose it from getCustomerCount() instead, so customer_count == 0 means "no guest count entered yet". ensureGuestCustomerCount now guards on that synced value, so an order whose guest count was entered on another device is not asked for it again. Every display goes through getCustomerCount(), so the values shown on the Guests button, the receipt and the preparation ticket are unchanged.

opw-6470180

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

Forward-Port-Of: odoo/odoo#285444
Forward-Port-Of: odoo/odoo#283002

## Steps to reproduce:
	- Install Planning and Employee
	- Create a working schedule for example 38h/week (8h,8h,8h,8h,6h)
	- Create two employees and assign the created working schedule to them
	- Create a shift in planning for the two employees for a week
	- Notice in gantt view the total allocated hours for each day are not calculated correctly

## Cause:
When calculating each cell's duration we fetch the resources' intervals while doing this here https://github.com/odoo/enterprise/blob/1851d3046682020686f517dec3c744d88a38b049/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L354-L359 we loop over the first interval and instead of pushing to the intervals we overwrite on the whole list with the interval we fetched so when it comes to the next interval it won't find any intersection so it will set the resourceIntervals to an empty array. So here https://github.com/odoo/enterprise/blob/1851d3046682020686f517dec3c744d88a38b049/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L231-L234 it will mess up the percentage calculation which will lead to wrong allocated hours numbers.

## Fix:
Instead of overwriting on resourceIntervals we push to it the intervals returned to keep the intervals for each resource.

opw-6316368

Forward-Port-Of: odoo/enterprise#123750

Changing a project's visibility fails when its documents folder contains a shortcut.
The visibility change is never applied and the following error is raised:
"You can not update the access of a shortcut, update its target instead."

### Reproduction steps

- Create a project and add a document to its folder.
- Create another document outside the project's folder.
- Create a shortcut to that document in the project's folder.
- Change the project's visibility.

### Cause

Changing a project's visibility updates the access rights of its folder and documents together.

The shortcut access check is meant to reject operations performed only on shortcuts. However, reading `shortcut_document_id` on a recordset returns the shortcut targets found across that recordset. Therefore, the presence of a single shortcut makes the check reject the whole operation.

This prevents regular documents and the project folder from having their access updated.

### Fix

Only reject access updates when all records involved are shortcuts.

This preserves the protection against changing shortcut access directly while allowing project access updates to include shortcuts alongside regular documents and folders.

opw-6472637

Forward-Port-Of: odoo/enterprise#129588
Forward-Port-Of: odoo/enterprise#128756

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

`avatar.mixin._avatar_generate_svg()` generates an auto-initial SVG avatar for any record without a real uploaded image (used by `res.partner`, `res.users`, and anything else inheriting `avatar.mixin`). The generated SVG opens with a single-quoted XML declaration: `<?xml version='1.0' encoding='UTF-8' ?>`.

When this content is served via `/web/image/...`, `guess_mimetype()` needs to determine its Content-Type since it's a computed value with no stored attachment metadata. On systems where the installed `libmagic` library classifies that specific single-quoted byte pattern as `text/xml` rather than `image/svg+xml`, the wrong Content-Type reaches the browser.

**Current behavior before PR:**

On affected `libmagic` versions/databases, an auto-generated avatar (a contact or user with no uploaded photo) gets served with `Content-Type: application/octet-stream` (or `text/xml`) instead of `image/svg+xml`. Browsers can't render that inline as an image, so instead of showing the colored-initial avatar, the browser downloads it as an unrecognized file. This affects any place these avatars are displayed: contact/user form and kanban views, chatter message authors, Discuss, etc.

Confirmed reproducible with `libmagic` 538 (`python-magic`), where the single-quoted declaration is classified as `text/xml`, while the exact same content with double-quoted attributes is correctly classified as `image/svg+xml`.

**Desired behavior after PR is merged:**

`_avatar_generate_svg()` now generates its markup with double-quoted attributes throughout, which is correctly sniffed as `image/svg+xml` regardless of the installed `libmagic` version. Auto-generated avatars render inline in the browser as intended.

No other code depends on the exact quoting of this generated SVG - `res_users.py` and `hr_employee.py` both only assign the returned bytes to an image field without inspecting their content. Avatar fields are computed and non-stored, so nothing needs to be migrated - every record gets the corrected markup on its very next read, with no backfill required.

Updated the two existing `test_avatar_mixin.py` tests that asserted the exact (single-quoted) SVG string, and added `test_generated_partner_avatar_mimetype` to assert the generated avatar is actually sniffed as `image/svg+xml`, so this can't silently regress. Ran locally: all 6 tests in `TestAvatarMixin` pass.

Forward-Port-Of: odoo/odoo#285081
Forward-Port-Of: odoo/odoo#283149

The "Import File" button on the dashboard card only shows up for bank
journals. Credit card journals are treated the same way as bank journals
pretty much everywhere else: the dashboard card itself, the statements list,
the "Transaction Feeds" setting on the journal form (where you can pick the
file import option), and even `create_document_from_attachment` in this
module, which already accepts them. So you end up with a credit card journal
set to import files but nothing on its card to actually do it, and people
assume the feature is simply not there.

Show the button on credit card journals too.

Steps to reproduce:
- Install account_bank_statement_import_csv (or any other import format)
- Create a "Credit Card" journal and set its Transaction Feeds to the file import option
- Go to the Accounting dashboard
- The bank journal card has an "Import File" button, the credit card one doesn't

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

Forward-Port-Of: odoo/enterprise#129546

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

After this [commit], companies outside the EU can use European VAT numbers.
Consequently, an Argentine partner can have a CUIT number such as ``BE0477472701``,
which is valid as a Belgian VAT number but not as a CUIT.
When printing the invoice, the ``l10n_ar_vat`` field is computed
from the partner's VAT and its value is passed to ``int()``,
causing a traceback at the following line:
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[commit]: https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0

Enterprise PR: https://github.com/odoo/enterprise/pull/127820

sentry-7666042143

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

Forward-Port-Of: odoo/odoo#284880
Forward-Port-Of: odoo/odoo#282454

**Steps to reproduce:**
- Install the `l10n_se` module and switch to a SE Company.
- Navigate to Invoicing > Configuration > Taxes.
- Create a tax and set the tax grid to `se_42`.
- Create and confirm an invoice for a Swedish customer using this tax.
- Navigate to Reporting > Tax Report.
- Check the amount of `Fält 42` under `Block E`.

**Observation:**
The `Fält 42 – Övrig försäljning m.m.` field shows the amount as negative 
instead of positive.

**Root Cause:**
At [1], the `se_42` formula is missing the negative sign.

These lines were missed by the `tax_tag_invert` revamp done in https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b.

**Fix:**
This commit adds the missing negative sign to the `se_42` formula, 
ensuring that the amount for `Fält 42` is displayed as positive in the 
Swedish tax report, similar to [2].

[1]:
https://github.com/odoo/odoo/blob/a56038c97e807388772ccc3a794cf0bf658a2076/addons/l10n_se/data/account_tax_report_data.xml#L356-L368

[2]:
https://github.com/odoo/odoo/commit/b8125f38e80c1977eedda5fc6b9466ece5e9fd89

opw-6457529

Forward-Port-Of: odoo/odoo#281925

When printing an invoice, a traceback will occur if the company's partner has an invalid CUIT.

Steps to reproduce the error:
- Install ``l10n_ar_edi`` module with demo data
- Switch to ``(AR) Exento`` Company
- Go to Invoicing > Configuration > Journals > Open ``Ventas Preimpreso`` journal >
  ARCA POS System: ``Electronic Invoice - Web Service`` > Save
- Create a new invoice with ``ADHOC SA`` partner > Confirm the invoice
- Open the ``(AR) Exento`` partner and set the VAT to ``BE0477472701``
- Open the Invoice > print

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'BE0477472701'
```

The issue occurs because when the partner's identification type is CUIT,
At [1] ``_run_check_identification()`` method does not include partners whose identification type has ``is_vat=True``.
As a result, CUIT is not validated by ``_run_check_identification()`` method in ``l10n_ar`` module at [2].
So, partner's ``l10n_ar_vat`` field can be computed as ``BE0477472701``.
Passing this value to ``int()`` raises the traceback during invoice printing at below line.
https://github.com/odoo/enterprise/blob/d55486866d09f8aa87c2003dab722cfa323068b4/l10n_ar_edi/models/account_move.py#L138

[1]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_latam_base/models/res_partner.py#L24-L30

[2]:https://github.com/odoo/odoo/blob/c2a39085ba0fbcf8a0e6a55228191e764499caea/addons/l10n_ar/models/res_partner.py#L55-L65

Community PR: https://github.com/odoo/odoo/pull/282454

sentry-7666042143

Forward-Port-Of: odoo/enterprise#129449
Forward-Port-Of: odoo/enterprise#127820

Currently, an error occurs when trying to fill in the company details from the General Ledger.

Steps to Reproduce:
 - Install `l10n_ae_faf` with demo data.
 - Switch to the `AE Company`.
 - Go to `Accounting` > `Reporting` > `Ledgers` > `General Ledger`.
 - Click on `your company` in the company details warning.

`AttributeError: The method 'account.report.action_fill_company_details' does not exist`

In this commit, the company details warning was added to the l10n_ae_faf module, similar to account_saft. 
However, the action_fill_company_details method is only defined in account_saft, which is not a 
dependency of l10n_ae_faf. Therefore, when the user clicks on "your company" to open the company 
form [1], the method is not available and an error is raised.

This commit ensures that action_fill_company_details is added to l10n_ae_faf so that clicking on 
`your company` opens the company form, as it does in account_saft.

[this commit]: https://github.com/odoo/enterprise/commit/dffc4412df42507457810a0895be3b8f4dc7ec3f

[1]- https://github.com/odoo/enterprise/blob/c8c2f13b7fd17e215044fc62774f2b4a378aaf8c/l10n_ae_faf/static/src/components/general_ledger/filters/warnings.xml#L3-L10

sentry-7676719103

Forward-Port-Of: odoo/enterprise#128327

Steps to produce:
---
- Install website_sale module without demo.
- Create a new product and publish it.
- From the incognito, go to shop and add that product to cart.
- While doing checkout > fill the address form.
- Add the all details including the company name and valid VAT.
  (ex. BE0477472701)
- Submit the form.

Issue:
---
- When a public or guest user submits a new address with both a contact name
  and a company name along with a valid VAT number, the contact's name was
  being overwritten with the company name.

Root cause:
---
- The _compute_is_company heuristic in res.partner automatically sets
  is_company=True for partners with valid VAT. In [commit]
  `_create_or_update_address`, the condition `elif partner_sudo.is_company:`
  was designed to rename existing companies, but incorrectly caught newly
  created individuals marked as companies due to VAT, causing their name to be
  overwritten instead of creating a parent company.

Solution:
---
- Replaced the is_company check with explicit conditions: the partner
  has no parent_id, has contact-type child_ids.
- This ensures the rename-company branch only fires for actual company
  heads that the logged-in user belongs to, not for individuals that
  happen to have is_company=True due to a valid VAT.

[commit]: https://github.com/odoo/odoo/commit/8f3a32170c842f5f42edc79bf8620276f0da7be4

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

Forward-Port-Of: odoo/odoo#285495
Forward-Port-Of: odoo/odoo#275044