Currently, when a BoM contains components with child BoM, clicking
`Compare BoMs` shows the immediate components only in list view. Users
still need to open each BoM separately to edit nested components.

This change will adds a new smartbutton that shows:
- Components: number of components of the BoM
- SubAssembly: number of sub BoMs inside the BoM

Clicking the smartbutton opens the list of exploded components by
following the hierarchy order, which provides a complete view of
the BoM structure in a single place, allows user to update nested
components and without navigating manually.

### About `forced_order_ids` context: ###
- The action uses a `forced_order_ids` context key to preserve the exploded
  hierarchy order instead of the model's default ordering when the list
  view performs a `search_fetch()`.

- When opening the exploded list view -> product form -> BoM of that product,
  `forced_order_ids` should be reset to `False`. Otherwise, if the same
  child BoM is added multiple times, the BoM show repeated BoM lines.
  [video](https://drive.google.com/file/d/1M5k4XXGvr8KASzhBsRRByV3vepM8BBn1/view?usp=drivesdk)

- When the user searches for a component through the search panel,
  `forced_order_ids` should filtered using the records returned by the `super()`
  call, which only contains the matched  records. Without that filtering, the
  search would stop working correctly and would return all `forced_order_ids`.
  [video](https://drive.google.com/file/d/1De0IfTyPPTjk02rCOh2yJPHa9wI0Zi_W/view?usp=drivesdk)

- It is also used to change the order of the fields in the search view, because
  when the list is opened from the `Components/SubAssembly` smartbutton,
  the component search should be on top, in other cases the BoM search should
  be on top.

Ent PR https://github.com/odoo/enterprise/pull/120254

task-6247051

Description of the issue/feature this PR addresses:

Rework the UX of the Jordan e-invoicing (JoFotara) flow: where submission
errors are reported, how a rejected invoice exposes its XML, where the
JoFotara fields live on the invoice, and how demo documents identify
themselves.

Current behavior before PR:

Configuration errors mask invoice-level ones, so the user fixes the settings
and gets a second round of errors. They arrive as a pop-up after the Send &
Print wizard is confirmed, one alert per invoice. The invoice form shows a
yellow banner and a "Download XML" link restricted to base.group_no_one, so a
rejected invoice offers no practical way to inspect what was sent. Demo mode
is invisible: the checkbox reads "JoFotara (Jordan EDI)" either way, and demo
PDFs and POS receipts look like valid fiscal documents.

Desired behavior after PR is merged:

All errors are reported together as danger alerts inside the wizard, before
submission — one alert per defect, with a "View Invoices" action listing every
invoice sharing it. A rejection opens a dialog with JoFotara's message and
buttons to copy it or download the submitted XML, for any user. The JoFotara
fields, plus Payment Method and "Reversal of", move into a "JoFotara" group on
the Other Info tab.

task-6321488


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

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

The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot.

This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small.

### Current behavior before PR:

The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found.

This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times.

### Desired behavior after PR is merged:

The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval.

This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios.

### Benchmarks

Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board.

| Work Order Duration | Before | After |
| --- |---|---|
| 1sec | ~2.5min | <1sec |  
| 1min | ~2sec | <1sec |

### References

opw-5437256


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

Forward-Port-Of: odoo/odoo#284278
Forward-Port-Of: odoo/odoo#246015

First commit fixes an issue where clicking a list item to center the map and open its marker's popup often did nothing at all. The pending record was stored in a plain, non-reactive field, only ever rechecked by updateMap()'s useLayoutEffect, which reruns on every patch of the component - but nothing about the click itself reliably causes a patch: closing pinListPopover (a mobile-only bottom sheet) only triggers one if it was actually open. On desktop, where it never is, closing it is a no-op, so no patch happens and the pending record is never rechecked. The popup would then only show up later, incidentally, whenever some unrelated interaction (toggling a group fold, expanding Unlocated, ...) happened to trigger a patch of its own.

Even when it did open, doing so before the map had finished panning to it made it visibly reposition/flicker, since it isn't tracked by Leaflet's own pan animation the way a native Leaflet popup would be.

Replace the deprecated Owl 2 useLayoutEffect compat shim with native onMounted/onPatched, and branch on whether pinListPopover is actually open: when it isn't (desktop), open the popup right away instead of depending on a patch that was never going to happen; when it is (mobile), wait for the patch that closing it triggers - the same one that recreates the markers - before opening the popup, so it anchors to the freshly created marker element instead of the stale one about to be removed. Also wait for the pan's moveend before creating the popup, to avoid the repositioning/flicker.

Second commit preserves map view state when navigating away to another view and returning, preventing the map from resetting to its default initial state.

The following state variables have been moved into the map model so they can be exported via `getLocalState` and restored upon remounting:
* **Group Folding:** Retains folded group states via `closedGroupIds`.
* **Unlocated Panel:** Maintains the expansion toggle state of `expandUnlocated`.

Since closed groups now outlive a reload, the groups a view folds by default can no longer be re-applied on every load: they come from `_getDefaultClosedGroupIds`, only consulted when the closed groups are (re)initialized, i.e. when the groupBy changes. Field service maps fold their material resources through that hook, instead of overwriting `closedGroupIds` after each load, which discarded both the restored state and whatever the user had folded.

The current user's position is instead persisted in `localStorage`, keyed by the view and action. When it comes from an address search or from the company's address, the actual coordinates are cached. When it comes from the browser's geolocation API, only the fact that it should be looked up again is cached, since GPS coordinates can quickly become stale.

Third commit refines list sidebar and group header styling. Group headers now span the full width of the list sidebar and darken on hover, like group rows in list views. The group pin icon is narrower so it no longer feels bloated next to the group name, and the Google Maps button in group headers no longer has a background or hover effect of its own.

Also unifies the "clickable" styling of located pins and unlocated records under a single class, and aligns the unlocated section's fold icon with the one used for other groups.

Record rows now carry their own horizontal padding instead of the list itself, so their hover background spans the sidebar's full width. The "my location" button icon uses the default icon size, and the pin list no longer keeps a stray bottom spacing.

Fourth commit adds the possibility to resize map view's side panel (pin list) similarly to what is done in the search panel or gantt view.

task-6431782

Currently, a sick leave for an employee is split into LEAVE110 (guaranteed salary, first 30 days) and LEAVE214 (no guaranteed salary, after 30 days).

This commit adds new split for Long term sickness (LEAVE280) for employee which is applied after 12 months sickness.

What changed:
- New helper `_get_l10n_be_long_term_sick_cutoff_date` return the cuttoff
  date at which a sickness chain crosses the 12-month threshold accounting relapse
  using `_l10n_be_get_sick_leave_twelve_months_cutoff_date` which is moved
  from `hr_payslip` to `hr_employee` as it will be commonly used for leave
  split and the paylsip work entry generation.
- New helper `_get_l10n_be_long_term_sick_split` takes the
  existing LEAVE110/LEAVE214 split and converts whatever part of it falls
  on/after the 12-month cutoff into LEAVE280. If the cutoff falls in the
  middle of a segment, that segment is cut in two.
- Applied this check to every place in `_get_l10n_be_sick_leave_split`
  that can return a final result.
- `_get_leave_work_entry_type_dates` (legacy support for old, unmigrated
  data) gets the same 12-month check before its existing 30-day check.

task-[6307896](https://www.odoo.com/odoo/project/1251/tasks/6307896)

Support Balance Deduction for China's Differential Taxation rules, where
businesses may issue Net Amount Fapiao or Full Amount Fapiao depending on the
applicable taxation method. The selected method determines how the deduction is
applied and how the corresponding Output VAT Offset Entries are generated,
ensuring accurate VAT accounting and traceability.

- Add invoice-line-level Balance Deduction management through dedicated wizard.
- Validate applicable invoice lines before posting, ensuring required deduction
  information is provided and taxes meet the supported percentage-tax
  requirements.
- Generate Output VAT Offset Entries according to the selected Differential
  Taxation Method:
- Link generated offset entries to the originating invoice and invoice lines for
  accounting traceability.
- Reverse previously generated offset entries when the invoice is reset to draft
  or Balance Deduction information is reset, preserving accounting consistency
  and auditability.

task-[6104958](https://www.odoo.com/odoo/project/967/tasks/6104958)

## Summary

POC exploring a better use of `num2words` in `res.currency.amount_to_text()` (core `base` module).

Today `amount_to_text()` converts the integral/fractional parts with a plain `num2words(...).title()` cardinal conversion, and always uses the currency's single-form `currency_unit_label`/`currency_subunit_label`. This is fine for English-like languages, but wrong for languages with grammatical number agreement: many Slavic languages use one of 3 noun forms depending on the last digit(s) of the amount (e.g. Ukrainian "гривня"/"гривні"/"гривень"), and some also need the numeral itself gendered (e.g. "одна гривня", not "один гривня", for 1 UAH).

`num2words` already ships this data per `(language, ISO currency code)` via `CURRENCY_FORMS` + `pluralize()` + `_money_verbose`/`_cents_verbose`, normally consumed through its own `to='currency'` mode. That mode is not used directly here because it changes Odoo's current sentence shape (it always renders the subunit clause, even when zero, and joins the two clauses with its own separator instead of a translatable "and").

This PR uses that per-language data to build just the two correctly-inflected words, and plugs them into Odoo's *existing* template:
- the zero-subunit clause is still dropped (no "...and zero cents"),
- the two clauses are still joined with the translatable `"and"`.

When `num2words` has no currency data for the `(language, currency)` pair, behavior falls back unchanged to the previous plain-cardinal + translated-label path.

## Example (Ukrainian / UAH)

| Amount | Before | After |
|---|---|---|
| 1.00 | `Один Hryvnia` | `одна гривня` |
| 2.00 | `Два Hryvnia` | `дві гривні` |
| 5.00 | `П'Ять Hryvnia` | `п'ять гривень` |
| 21.56 | `Двадцять Один Hryvnia and П'Ятьдесят Шість Kopiyka` | `двадцять одна гривня and п'ятдесят шість копійок` |

(English/EUR and other currencies `num2words` has no data for are unaffected.)

## Scope / open questions (see inline code comments)

- This is a POC: only currencies `num2words` explicitly models (`CURRENCY_FORMS`) get the improved output; everything else keeps today's behavior byte-for-byte.
- The untranslated literal `"and"` in some locales is a pre-existing translation-coverage gap, unrelated to this change.
- `num2words`' own data isn't uniformly correct/complete across all its language modules (e.g. English `EUR` forms don't pluralize `"euro"` upstream) - that's an upstream data quality question, not something this PR should paper over.
- Longer term this raises the question of whether `currency_unit_label`/`currency_subunit_label` should stay only as the fallback path.

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders).
3. Close the session.

The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes.

Cause
-----
`_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments.

`_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time.

opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched.

Fix
---
Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment.

Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards.

Benchmark
---------
Closing a session of 2081 invoiced orders on a copy of the customer database:
- before: 558s
- after: 54s

opw-6458271

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

Forward-Port-Of: odoo/odoo#285183
Forward-Port-Of: odoo/odoo#281495

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

*: pos_self_order, website, portal, portal_rating, project,
website_event, website_links, website_mass_mailing, website_slides,
account_payment

Several places create a Bootstrap 5 component (Carousel, Modal,
Dropdown, Tab, Popover, Tooltip, Collapse, Offcanvas) without ever
calling .dispose() on teardown. Bootstrap keeps every instance in a
page-global Map (not a WeakMap) keyed by its DOM element (see
`elementMap` [1],
so a missing dispose() permanently leaks the element.

Three helpers centralize the fix and dedupe disposal per instance
(safe even if several owners obtain the same instance, e.g. a popup
surviving a builder re-render): getOrCreateBootstrapInstanceForInteraction
and getOrCreateBootstrapInstanceForEditorPlugin get-or-create an
instance and register its disposal on the owner's teardown, for
Interaction and Plugin owners respectively; useBootstrapInstance is the
Owl hook equivalent for Components. disposeBootstrapInstance disposes
an instance right away (e.g. from a hidden.bs.modal handler) through
the same dedup tracking, so it is never disposed twice.

Mostly invisible in normal usage, but a severe leak in the JS unit test
suite (thousands of mount/unmount cycles in one browser session):

| Run                          | Scope | Memory before | Memory after | Percent |
|-------------------------------|-------|--------------:|-------------:|--------:|
| carousel_hook.js (16719 tests) | all   | 934.5 MB      | 363.2 MB     | -61%    |

Runbot errors:

- https://runbot.odoo.com/odoo/error/945770
- https://runbot.odoo.com/odoo/error/945772

[1]: https://github.com/odoo/odoo/blob/6d2fda1/addons/web/static/lib/bootstrap/js/dist/dom/data.js#L23

Since revamp of the countdown [1], this test fails sometimes.
This happens because the countdown schedules its renders on the exact
start of the next second (1000 - Date.now() % 1000 => 000 ms), and
because hoot uses performance.now() for timers, but Date.now() for date,
which can differ by a fraction of a millisecond [2].
So unless time is frozen, we can have such an issue:
- we advance time by a second
- `performance.now() + offset` triggers an interval function execution
- countdown uses Date.now(), which might still be on the previous second
=> test fails as the seconds didn't update.

This is fixed by freezing time.

Also, for readability we add two helpers to read hours and seconds.

[1]: https://github.com/odoo/odoo/commit/2ff879a3532b97a424400cad63fd32ef05e2d7f4
[2]: https://stackoverflow.com/questions/30795525/performance-now-vs-date-now#:~:text=On%20non%2DFirefox%20browsers%2C%20Date.now()%20is%20accurate%20to%20~1ms%20and%20performance.now()%20is%20accurate%20to%20~0.1ms%20unless%20in%20certain%20cases.%20If%20you%27re%20using%20Firefox%2C%20the%20accuracy%20is%20down%20for%20both%20to%202ms.%20They%20are%20both%20extremely%20fast

Since https://github.com/odoo/enterprise/commit/91a97dd1b9085ba348d0ecb4479cf96422ed4168, the
ContrastPlugin resolved a different background in community and in
enterprise, and thus adjusted the same content to a different color on each
side: it read `--o-control-panel-background-color`, which enterprise now
maps to `$o-webclient-background-color` (#f8f9fa) while community keeps
`$o-view-background-color` (#FFFFFF). White text on white was therefore
darkened to rgb(183, 183, 183) in community and to rgb(178, 178, 178) in
enterprise, and the editor tests could only pass on one side.

That variable was never the control panel's business: it was exposed as a
CSS variable by https://github.com/odoo/odoo/commit/26a85df9df766f2f56431b491cf692488d426524 for the sole use of
the plugin, at a time when it happened to be the background the editable is
drawn on. Rename it to `--o-html-editor-background-contrast`, declare it in
html_editor for both the backend and the frontend, and default it to the
view background. The plugin no longer depends on a design decision that is
not its own, and any context rendering the editor on another background can
override it. The control panel gets its plain SCSS value back, as nothing
was overriding the variable.

The colors expected by the tests are the same again on both sides, which
partially reverts https://github.com/odoo/odoo/commit/443fdc2edc017ba872b411df79f91df4afdd3951: only its test
changes are undone, its website SCSS change is kept.

Before this commit, clicking a notification of an inaccessible record in the messaging menu opened no dialog, and the nightly build failed on

    FAILED: [4/8] Tour access_inbox_records_tour -> Step .o_dialog
    .o-mail-Message-body:text(Message in inaccessible record).
    Element has not been found.

This happens because the messaging menu shows the message in a dialog from the rejected promise of the action, while the action service restores the controller displayed before the failure, and `_updateUI` closes every dialog at the end of a restore. A dialog the user had opened before the failed click is closed the same way.

This only shows since "[IMP] web, project: enable test_documents_full eslint" *: the group check that commit moves to the end of a cog menu `isDisplayed` ran on every view, and its await delayed the mount of the controller, so the stack was still empty when the error arrived and the error path restored nothing.

This commit fixes the issue by keeping the dialogs open when the restore recovers from a controller error, as such a restore brings back the controller that was already displayed.

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

* https://github.com/odoo/odoo/pull/284082

Steps to reproduce:
- Have a paid order with a product ordered once
- Open the ticket screen, select that order and its line
- Scan a product barcode with a keyboard-wedge scanner

Issue:
"Maximum Exceeded - The requested quantity to be refunded is higher than the ordered quantity. 6 is requested while only 1 can be refunded." When the line holds enough quantity no dialog is shown at all and a refund quantity taken from the barcode is silently set.

Cause:
A keyboard-wedge scanner types the barcode as a burst of keystrokes. The number buffer discards such bursts by waiting
barcodeService.maxTimeBetweenKeysInMs before handling the keys it collected and dropping any batch of more than two, but only when its holder asks for it with `useWithBarcode`. TicketScreen never set the flag, so its buffer handled every keystroke on its own and the digits of the barcode reached _setToRefundDetail as the refund quantity. ProductScreen, OrderSummary and PaymentScreen all set it.

Fix:
Set `useWithBarcode: true` on the ticket screen number buffer. Since the keys are now handled with a delay, capture the buffer before the selected order or orderline changes, so that a keystroke is applied to the line that was selected when it was typed and not to the next one.

opw-6465148

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

Forward-Port-Of: odoo/odoo#285083
Forward-Port-Of: odoo/odoo#281962

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

*=account, hr_timesheet, loyalty, mrp_subcontracting, project, purchase, sale, website_crm_partner_assign

Steps to reproduce:
1. install sale
2. Create and confirm a sale order for a portal user
3. Login as a portal user
4. Open sale orders

Issue:
- Breadcrumbs are not visible beside the title.

Cause:
- After this commit https://github.com/odoo/odoo/commit/bba2fc505f5d0b4770eacc6877155b1aeda6d772
Variables are passed as attributes directly on the element, but breadcrumbs_searchbar
was passed to portal_layout, but the nested portal_searchbar no longer received it.
As a result, portal list pages rendered their title instead of the breadcrumb home link.

Solution:
- Pass breadcrumbs_searchbar directly to portal_searchbar

Alternative:
- An alternative would be to propagate t-call parameters to slot content
in QWeb or changes the condition for breadcrumbs visibility

related enterprise pr: https://github.com/odoo/enterprise/pull/118352

opw-6232899

Forward-Port-Of: odoo/odoo#266020

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

| //////////// | Projects view | Project tasks view |
|--------|--------|--------|
| Master | <img width="274" height="122" alt="image" src="https://github.com/user-attachments/assets/c72473b4-e5dd-4c59-be9b-9be4b4a030fa" /> | <img width="362" height="127" alt="image" src="https://github.com/user-attachments/assets/2a130494-d8c9-4316-be16-d0dc00213b49" /> |
| This PR | <img width="294" height="117" alt="image" src="https://github.com/user-attachments/assets/75d3d21f-6e6c-4dc9-8aca-96a9f4002015" /> | <img width="384" height="154" alt="image" src="https://github.com/user-attachments/assets/2a8c66f8-0c80-488d-a459-2e3760c3e745" /> |


Some screens don't use the standard control panel directly, they make their own copy of it to add extra buttons. Project tasks is one of them.

Since Commit[^1], the Enterprise styling of the view switcher was added to the control panel too late, so those copies were made before it existed and never got it. Their switcher kept the default look instead of the new rounded one.

The manifest already had a rule to add the file early, but it came after the line pulling in the whole search folder. The first mention of a file wins, so that rule was silently ignored. Moving it above makes it apply.

Whether it shows depends on which apps are installed: e.g `accountant` loads `web_enterprise` early and hides the problem, which is likely why it went unnoticed.

[^1]: https://github.com/odoo/enterprise/commit/91a97dd1b90

task-6518773

Issue before this commit:
=========================
When a lot-valuation-enabled product uses FIFO costing and all quantities from
a lot are consumed, the lot's standard price is reset to 0.

Steps to Reproduce:
=========================
- Install the stock_account and purchase modules.
- Create a lot-tracked product and enable Valuation by Lot/Serial, 
  set FIFO as the costing method.
- Create a PO for 5 units of the product with a unit price of 5.
- Receive the products and check the lot's standard price; it is set to 5.
- Sell all the product quantity for that product.
- Open the lot form.

Observation:
The lot's standard price (cost) is reset to 0.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/276163), the FIFO valuation logic computes the standard price using:
- std_price = value / quantity if quantity else 0

When the lot quantity becomes 0, the quantity used for this computation is also 0. 
As a result, the standard price is reset to 0 even though the lot's historical cost is still relevant.

With This Commit:
=========================
Keep the lot's standard price when its quantity reaches 0, instead of resetting it to 0.

Steps to reproduce:
- create a "Buy 2 Take 1" program whose rule and reward both target a product tag containing several products
- in the PoS, add one of the tagged products to the order
- set its quantity to 3 with the numpad

Issue:
The free product is not given. Clicking the product a third time instead of typing the quantity does give it, and so does a program whose reward is a single product.

Cause:
A reward whose products come from a tag is multi_product, so getClaimableRewards never computes its unclaimed quantity and the auto claim of updateRewards skips it: which product to give out is unknown. The only place claiming such a reward is addLineToCurrentOrder, which resolves it with the product that was just added. Setting a quantity does not go through it, hence the difference.

Fix:
Resolve the reward product the same way when auto claiming: the product of the line being worked on, or, failing that, the only reward product the order contains. The reward then follows the quantity of any of the tagged products, not only of the first one added, and the cashier is still asked when the order does not settle the choice.

opw-6430385

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

Forward-Port-Of: odoo/odoo#284777

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

This is one of many errors fixing the FAIA report, which is the SAF-T report for Luxembourg. See PR #113316 for a list of similar PRs.

### Error 1: Negative tax amounts

Auditors from Luxemborg provided one Odoo user with analysis files of their FAIA xml report. The following discrepancy was present in more than 300 lines:

`[TaxInformation/TaxAmount/Amount] # is negative. Only postive values are admitted. The sign is automatically determined by the corresponding CreditAmount (-) Or DebitAmount (+) on the same Line.`

This discrepancy was caused by two different scenarios. The first was a negative `unit_price` line, such as a Discount product. The second was a tax with negative and positive repartition lines, such as a tax with xml ID `lu_2015_tax_AP-EC-17`.

Luxembourg officials confirmed the following behavior:
1. The TaxInformation/TaxAmount/Amount element must be positive.
2. The TaxInformationTotals/TaxAmount/Amount element may be negative.
3. There may only be one TaxInformationTotals element per TaxCode in an Invoice element.

This commit ensures that these conditions are met for the FAIA report. I'm not sure if the TaxInformation changes should also be applied to the base `account_saft saft_report.xml` file.

### Error 2: SoftwareVersion

The SoftwareVersion element is limited to 18 characters. The relevant error from a customer's analysis file is below.

Error:  Value exceeds maxLength of "18".

### Error 3: CurrencyAmount

The `account_saft` method `GeneralLedgerCustomHandler._saft_fill_report_tax_details_values()` does not report the amount of tax in foreign currency, instead replacing this value with the amount in company currency. No errors prompted this change; it just seems wrong on its face.

### Error 4: 
PR #113720 ensured that the TaxType element is always TVA. This means that the TaxType should no longer should be ignored in our example documents.

### Error 5: Schema validation failure

The elements Inovice/CustomerInfo and Invoice/SupplierInfo are defined with the element `<xs:choice>` in the XSD file linked below. Only one can be present at any time, not both.

https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. note: currently the link is broken.

PR #100749 allowed many parts of SAF-T code to display both customer and supplier data, including these elements. This commit ensures that the elements are mutually exclusive.

opw-6344914 [Link](https://www.odoo.com/odoo/project.task/6344914)

Forward-Port-Of: odoo/enterprise#129043
Forward-Port-Of: odoo/enterprise#126121

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1

### Cause of the issue:

This is the exact use case already fixed in
85dd3369ed17b98b2ce485be04f140cf4cfa8aa3, which stamped the finished move with a `location_final_id` pointing at WH/Stock so that the move contributes to the forecast there even though its `location_dest_id` is the intermediate WH/Post-Production.

That fix was reverted in practice by 42275f83dc5350822a625e19d65148e8b41ab1d4, which replaced the value with `mo.location_dest_id`:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_move.py#L466-L467

Its reasoning was that in a single-warehouse setup `location_dest_id` equals the warehouse stock location, so the behaviour would be unchanged. That holds in 1 and 2 steps, where the extra step is on the component side and only moves `default_location_src_id` to the pre-production location. It breaks in 3 steps, the only mode that also moves `default_location_dest_id`, to the post-production location: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L246-L247 and `_compute_locations` propagates it to the MO:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/mrp_production.py#L334-L341

WH/Post-Production is a sibling of WH/Stock under the warehouse view location, not a child of it. Since `location_final_id` takes precedence over `location_dest_id` for the non-done part of the move chain:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L331-L334 the finished move stopped being counted in the WH/Stock forecast.

Why the test did not catch it:

`test_3_steps_manufacturing_forecast` stayed green through the whole regression, because it scoped `virtual_available` with a `location_id` context key. `_get_domain_locations` only reads `location` and `warehouse_id`; `location_id` is silently ignored: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L284-L287 The call therefore fell through to the branch scoping the forecast to every warehouse view location:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L303-L309 and the warehouse view location is the common parent of both WH/Stock and WH/Post-Production. The assertion held regardless of where `location_final_id` pointed, so the test was a false positive from the start: it also passes with 85dd3369ed17b98b2ce485be04f140cf4cfa8aa3 fully reverted. Using the `location` key makes it fail without the fix and pass with it.

### Fix:

Neither fix proposition was right on its own; each one was correct only in its own scenario. The`mo.warehouse_id.lot_stock_id` resolves the warehouse from the components, so it points at the wrong warehouse as soon as the finished product is produced for another one. `mo.location_dest_id` is the post-production location as soon as the warehouse manufactures in 3 steps, so it drops the quantity from the forecast of the manufacturing warehouse itself.

What separates the two is not the warehouse but whether the destination is a transit step. In 3 steps the finished product only reaches the stock through the post-production push rule: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L57 so the final location is the stock of the warehouse owning that destination. Any other destination is already final and is kept as is, which leaves cross-warehouse MOs and destinations set to a sub-location of the stock untouched.

The rule's destination is read rather than `warehouse.lot_stock_id` because a push move takes its destination from the rule and not from the operation type:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_rule.py#L256-L260
so the forecast stays correct when the store step is reconfigured to land somewhere else than the warehouse stock.

The rule is looked up on `pbm_route_id` by its `picking_type_id` instead of through `warehouse.sam_rule_id`, because that field is no longer set. It used to be an entry of `_generate_global_route_rules_values`, and it is that entry which made the generic warehouse machinery create the rule and store it back on the warehouse:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_warehouse.py#L403-L410
11e69870db1c49d9a6af79ffd263e4e162b34b6b removed it when the post-production step stopped being a pull rule on the Manufacture route and became a push rule generated from `get_rules_dict`. Only the field declaration was left behind, and nothing writes it any more:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L21-L22
so reading it would silently give an empty recordset. The lookup is not delegated to `_get_push_rule` to avoid a search per finished move.

opw-4882390

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

Forward-Port-Of: odoo/odoo#285185
Forward-Port-Of: odoo/odoo#283234

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

# How to reproduce
- Activate the stock_landed_costs module
- Enable Dropshipping
- Create a product with :
	- Category :
		- Costing Method : AVCO
		- Inventory Valuation : Perpetual
	- Routes : Dropship
	- Atleast one vendor
- Create a SO for that product
- Confirm the SO & then Confirm the associated PO
- Login as an user with "User" rights for Inventory
- Try to validate the Dropship transfer

# The issue
You get an access error. If the same flow is done with a product with a Standard Price costing method, then the Dropship is properly validated

# Cause
When validating the Dropship, we'll call `_action_done` on the moves. This will trigger an update of the standard price of the product : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L177 https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L345-L349

Since we're in avco, this will run the `_run_average_batch` method : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/product.py#L675

That will fetch the value of each moves. For the Dropship moves, it'll do so by calling the `_get_value()` method :
https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/product.py#L486

This method will compute the value of the move, notably by using the associated landed costs : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L431 https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_landed_costs/models/stock_move.py#L14

Now the issue is that this computation calls `_read_group` on 'stock.valuation.adjustment.lines' that are retricted to inventory administrators :
https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_landed_costs/models/stock_move.py#L11 https://github.com/odoo/odoo/blob/5f6fb63d5d7585805642c702d096b2f882e73761/addons/stock_landed_costs/security/ir.model.access.csv#L4

# Proposed solution
Get the value of the move in sudo like previously done in the flow : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L314

opw-6323645

Forward-Port-Of: odoo/odoo#284251
Forward-Port-Of: odoo/odoo#273102

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

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#284606
Forward-Port-Of: odoo/odoo#276905

Steps to Reproduce :
1. Go to Website → Edit Mode
2. Add a snippet with button
3. Click on button and change its type to : " Custom"
4. Apply the gradient type color in fill color option
5. Apply any color in text color option
6. You will notice that the gradient type color in fill color option is
removed.

Problem:
Since [this commit][1] new button style options have been added to the
sidebar. If one changes the style of a button to custom, changes the
background to gradient, and tries to change the text color, the
background gradient is removed.

Cause:
Whenever a gradient is added either to text or as a background, it is
applied as a background image. In the case of a text gradient, an
additional class, `text-gradient`, is applied for correct styling. Once
a change to either color or background/fill is applied that is not a
gradient color change, the background image of the element would be
reset to nothing. This is the result of [this line][2] from a [previous
commit][3]. In the case of a button, this meant changing the font
color would reset the background. That is not the desired outcome.
The flaw was only discovered once new options were added to change
non-text/font elements' backgrounds to gradient.

Solution:
An additional check has been added to see if the element being edited
is text. If so, and it's a gradient style being changed, we remove the
background image. Otherwise it is kept so that the button case from
above is resolved.

[1]: https://github.com/odoo/odoo/commit/2bf1db001b195480b963b338583c170aa1c009a3
[2]: https://github.com/odoo/odoo/blob/8e0845712f462ecfafd2176406dcbafc869a5564/addons/html_editor/static/src/main/font/color_plugin.js#L575
[3]: https://github.com/odoo/odoo/commit/8e0845712f462ecfafd2176406dcbafc869a5564

task-6247134

Forward-Port-Of: odoo/odoo#285063
Forward-Port-Of: odoo/odoo#279070

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

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

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

Steps to reproduce
---
1. Install sale_timesheet_enterprise.
2. Go to Timesheets > Configuration > Settings (as Admin).
3. Disable the "Billing Rate Indicators" setting and enable timesheet assistant.
4. Log in as a normal user with "Timesheets > Own timesheet" access.
5. Open the Timesheets app.

Issue
---
The "Configuration" menu is completely hidden. The regular user cannot access the "Assistant Rules" menu unless they turn on debug mode.

Cause
---
When the billing rates feature is turned off, the _load_menus_blacklist function hides the Enterprise Configuration menu. The logic used an and condition, meaning the menu was only kept visible if the user was an Assistant AND had Manager/Admin rights. This locked out standard users.

Fix
---
Change the blacklist condition. Allow the Enterprise Configuration menu to stay visible if the user needs it for the Assistant feature (when UoM is not Days), OR if the user is a Manager/Admin.

References to check other issues
https://github.com/odoo/enterprise/pull/120609
https://github.com/odoo/enterprise/pull/117984

task - 6470183

Forward-Port-Of: odoo/enterprise#128727
Forward-Port-Of: odoo/enterprise#128096

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