This update enhances the user experience by ensuring that POS categories are consistently accessible throughout the Point of Sale interface. Previously, categories were hidden, making it less convenient for users to manage products. This change improves workflow efficiency and simplifies product organization within the POS system.

POS categories should be accessible at all times.

Back-port of: fd30d8220c7bb6a399aa18654322a20b53ddd76c Task-3673139

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

This update improves the speed of spreadsheet evaluations, particularly for the 'BE Timesheet' dashboard on odoo.com. By returning error values instead of throwing errors during loading, the initial evaluation time has been reduced by approximately 20%, leading to a smoother user experience.

At the initial evaluation of a spreadsheet with pivots/lists, almost all cells are in error because they are loading. But throwing errors is slow.

With this commit, instead of throwing loading errors for every single cell, the error is returned.

This commit improves the first evaluation time of spreadsheet the "BE Timesheet" dashboard on odoo.com by ~20%, from ~1716ms to ~1365ms (master)

Task: 3736190



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

This update resolves an issue where time-off reports were missing details for leave allocations. A recent change removed a key field, preventing the system from correctly linking to the allocation record. This fix ensures that all time-off reports accurately display the associated allocation information.

Steps to reproduce:
-------------------
- go to time-off analysis (by type);
- group by "Requet Type" and use list view;
- click on an allocation;

Issue:
------
We don't have the record for this allocation.

Cause:
------
Commit [^1] removes the `allocation_id` field, so it is no longer possible to retrieve a record from the
`hr.leave.allocation` model.

Solution:
---------
Place the allocation id in the `leave_id` field and use the `leave_type` field to determine the model
(`hr.leave` or `hr.leave.allocation`).

opw-3748884

[^1]: a1949ca541d760462add25995f139d1fb59f27d8

Forward-Port-Of: odoo/odoo#157204

This update resolves issues with the karma wheel's display, specifically addressing text overflow and incorrect rank calculations. The fix adjusts the wheel's size and text formatting to ensure accurate and consistent presentation across languages, improving the user experience.

How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"

The design of the karma wheel is broken because the translation for "Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k xp pour passer au niveau supérieur"). While in French the text go outside the wheel and it appears clearly broken, it is also the case in English as the rank name is hidden due to the length of the text (for example when gaining one karma: 7.49k is displayed instead of 7.5k which takes more place).

To avoid modifying the template "profile_next_rank_card" that could break community overrides, we solve this problem in css by increasing the karma wheel size and the precentage of width occupied by the text inside the wheel. We also reduce the vertical margin between the rank name and the descriptive text and reduce the line height to avoid the text to overlap with the wheel. And if the text is still too large for some language it will be truncated and an ellipsis will be used.

Technical note: we do the change in website_profile.scss (and not in website_slides.scss) because it applies to both karma wheel: the one on course home page and the one in the profile page.

[FIX] gamification: fix incorrect next rank

How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"

The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be: 4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next level is doctor at 10k).

We solve that issue by fixing the method that determine the next rank (see technical note for more details).

Technical note: the problem occurs because the admin user has the rank 4 but its field next_rank_id is null while there is a level 5. In that condition, the method _get_next_rank returns an empty recordset while it should return the rank 5. We simplify that method to always return a rank if there is one suitable (if you reach the last level, there are no next level).

(Initial PR in saas-16.1: odoo/odoo#151372)

Task-3617054

Forward-Port-Of: odoo/odoo#157585

This update prevents users from completely removing the l10n_mx_edi module within Odoo's settings. This ensures continued compliance with Mexican tax regulations and avoids potential disruptions to financial reporting. The change maintains the integrity of our Mexican tax functionality.

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

Forward-Port-Of: odoo/odoo#157439

New spreadsheet dashboards are no longer shown automatically in the main dashboard view while they are still being prepared. Users can now publish a dashboard when it is ready, reducing the risk of unfinished dashboards being seen by the wider team.

While you are creating a new dashboard, you don't want that dashboard to be visible on the main dashboard view because it's a work in progress.

With this commit, we add a boolean field to publish the dashboard to the main action. It's not published by default.

Task: 3640421

Point of Sale users can now choose from predefined internal notes in the note popup, making order preparation instructions faster and more consistent. Notes are displayed as separate pill-style options instead of a single line, improving readability and ease of use.

- Added a predefined note model
- Added these notes on toggle buttons on the internal note popup window
- Instead of having all notes on one line we now have them as seperated pills

TASK-ID: 3764484
Community: https://github.com/odoo/odoo/pull/156664

Activity Plan screens are easier to use on smaller devices thanks to mobile-friendly kanban views. The update also improves guidance shown to users when setting up activity plans, helping teams get started more quickly.

To improve usability on small device, we add the kanban view for them (only) in the following view:
- mail.activity.plan
- mail.activity.template
- mail.activity.type

We also the following improvement:
- improve the action helper for the plan (unfortunately the help is duplicated for each action)

Task-3639909

Spreadsheet users can now adjust pivot table row and column groupings directly from the side panel. This makes spreadsheet analysis more flexible and removes an unused refresh button from pivot, list, and chart panels to simplify the interface.

Fixed an issue where updating an eBay-linked product could apply changes to the wrong product. This helps prevent accidental listing or product data mistakes in sales operations using the eBay integration.

The appointment calendar’s availability sharing button has been repositioned and cleaned up so it displays correctly across desktop and mobile views. This makes it easier for users to find and use the sharing action without layout issues in Appointment, CRM appointment, and Knowledge calendars.

*appointment_crm, knowledge

### Adapt availabilities button 
In commit d7f1b4bea7c7586a0d26015ed353b97dd3f18721 "Share availabilities" button was moved to the control
panel.
This broke the visual aspect of the button's contents mainly because there wasn't enough space for it.
Since the revamp of the calendar in https://github.com/odoo/odoo/pull/138670 we introduce a header for the
calendar.
In this PR we move the button between the header and the sidebar toggler on desktop and to the bottom of the screen on mobile. We also fix its broken elements.

Requires: 
- Community PR: https://github.com/odoo/odoo/pull/144169

task-3617561
part of task-3575827

|Before|After|
|-----|-----|
| ![Screenshot 2023-11-29 at 13 15 02](https://github.com/odoo/enterprise/assets/19491443/314b42d9-0dd9-4302-9c88-f5eac63c2c58) | ![Screenshot 2023-11-29 at 13 15 12](https://github.com/odoo/enterprise/assets/19491443/a117d5ba-3e57-46f6-af7d-c315f1845c45) |
| ![Screenshot 2023-11-29 at 13 14 59](https://github.com/odoo/enterprise/assets/19491443/24a37cf1-6057-450b-a7df-e1f3d37411d6) | ![Screenshot 2023-11-29 at 13 15 15](https://github.com/odoo/enterprise/assets/19491443/41c18469-ed49-4bf5-8b91-138f047d2506) |
| ![Screenshot 2023-11-29 at 13 14 55](https://github.com/odoo/enterprise/assets/19491443/6fe5f342-21df-423a-8d6e-fab2ecd82fe8) | ![Screenshot 2023-11-29 at 13 15 19](https://github.com/odoo/enterprise/assets/19491443/03565cdf-02c5-4f6b-8e37-24b515f0838b)|

This improvement adds the ability to use the Send & Print feature with only specific options enabled, while automatically disabling all others. Previously, unchecked options would revert to their default computed values. This gives users more precise control over which actions are performed when sending and printing documents.

…en options

Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value.

This update prevents users from accidentally uninstalling the Mexican Electronic Invoice (EDI) module through the settings interface. By restricting this action, the system ensures that critical Mexican tax compliance functionality remains active and cannot be disabled unintentionally, protecting your business from compliance issues.

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

Forward-Port-Of: odoo/odoo#157439

This improvement allows locked purchase orders to be matched with OCR-scanned invoices. Previously, locked POs could not be matched during the invoice processing workflow. This enhancement streamlines the invoice matching process by removing this restriction, making it easier to process invoices against locked purchase orders without manual intervention.

This change allows for locked purchase orders to be matched with OCR

Task: 3798080

Forward-Port-Of: odoo/odoo#157485
Forward-Port-Of: odoo/odoo#157386

This update improves the Send & Print feature by allowing users to select only specific options they want to use, with all other options automatically disabled. Previously, unselected options would use default computed values, which could lead to unintended actions. This gives users more precise control over document sending and printing behavior.

…en options

Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value.

This update resolves a bug in inter-company invoicing that occurred when processing analytic distribution data. The system was incorrectly trying to parse multiple IDs as comma-separated strings, which caused invoicing failures between related companies. This fix ensures invoices are properly created and processed across company boundaries.

[FIX] account_inter_company_rules: Fix inter-company invoicing issue
This fix is to solve a bug that was introduced due to the new change to multi ids in the key of the analytic distribution where the existing code does not consider that and ends up trying to parse a bunch of comma-separated, string of ids.
opw-3756270

Fixed an access error that prevented users from viewing bank accounts in the Accounting Dashboard when using child companies or branches. This fix enables proper access to child bank journals, allowing multi-company setups to function correctly in the accounting module.

Steps to reproduce:
- Create a child company/branch
- Create a child Bank Journal for the Child Company
- Set on demo use the default company as the child company
- Connect with demo
- In the Accounting Dashboard try to open the Child Bank

Issue:
Access Error

opw-3746324

This update fixes the appearance of account reports when using dark mode, ensuring they look consistent with their light mode versions. Users who prefer dark mode will now see properly formatted and visually balanced financial reports without display inconsistencies.

In this fix we made the account reports in dark mode look similar to their light mode counterparts

task: 3770541

Fixed an issue where tax groups without a country assignment were not appearing in the tax report configuration screen. This ensures that all tax groups are properly visible when setting up new tax reports, improving the user experience during tax report configuration.

Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group.
Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show.

X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a

Forward-Port-Of: odoo/enterprise#58328

This fix resolves errors that occurred when employees clicked "I take it" or "I am unavailable" buttons in the planning interface or planning emails. The issue was caused by permission checks failing during the shift assignment process. The fix ensures these buttons now work smoothly without access errors, improving the employee scheduling experience.

This commit fixes some access rights errors that were occuring when clicking on buttons that would change the resource_id in the planning front-end or from the planning automatic emails.

Behaviour prior to fix:
Clicking on "I take it", "I am unavailable" in the front-end or in the automatic planning emails would lead to a planning rights error.

Cause:
When changing the resource_id from the front-end we do it trough sudo. Apparently, when redirecting the user and fetching the edited slot, the env changes, the sudo is lost, and the slot_properties field is recomputed. The access rights error is raised from the re-computation of that field.

Fix:
We call the field after changing the resource so it is re-computed with sudo. Then, when re-directing, there is no-need for re-computation and thus we don't get an access rights error.

task-3793005

This update restricts the CodaBox module to companies that have an Accounting Firm designated, preventing non-accounting firms from using features that could create unnecessary support tickets. The module now hides CodaBox connection settings and raises errors during installation if no Accounting Firm is configured. Settings section names have also been reorganized for clarity.

This fix ensures that when closing a tax period, the system uses the correct custom report handler associated with the report instead of always defaulting to the standard tax report handler. This resolves issues where reports with custom handlers were not being processed correctly during tax period closure.

If a report uses a `custom report handler`, he might not use the default `account.tax.report.handler`.

We should instead use the `custom report handler`
associated with the report.

task-3757417

This update fixes errors that occur when using Odoo's accounting features on Windows systems. Certain system configuration settings are unavailable on Windows, which was causing the application to crash when users tried to run reconciliation models or perform banking operations. The fix adds proper fallback handling for these missing settings so the system works smoothly on both Windows and Linux.

### Summary

Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741.

### Steps to reproduce

* make sure you're on an instance running on Windows [^1]
* install `account_accountant`
* go to any reconciliation model that has Auto-Validate enabled
* click on 'Run manually'

You should be met with a traceback: `TypeError: '<' not supported between instances of 'int' and 'NoneType'`

### Cause

The system expects `tools.config['limit_time_real_cron']` to be a number. However, on Windows systems, `limit_time_real_cron` and a few other configuration keys are disabled, and always set to `None`.
See https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L488-L497

opw-3752912
opw-3780549

[^1]: For testing on Linux, you can modify these two conditions to behave as if `os.name != 'posix'`:
https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L494-L497
https://github.com/odoo/odoo/blob/7fc9a0bd0a1871b14c508cce73e0f103de9c1283/odoo/modules/registry.py#L50-L57

Forward-Port-Of: odoo/enterprise#57728

This fix resolves an issue where canceling and resetting a renewal quotation to draft would lose the renewal status, causing incorrect transaction logs when the quote is later confirmed. The update ensures that renewal quotes maintain their proper status throughout the cancellation and reset process, preventing missing transfer records in the system.

Before this commit, when a salesperson canceled a renewal quotation, and reset it to draft, the subscription_state '2_renewal' was lost. It would affect the sale_order_log upon confirmation of that renewal and the sale.order.log would not be correct. In that case, there would be a missign transfer log.

taskid: 3651477

This update corrects the CSV export header format for Danish accounting reports to comply with official government documentation requirements. The header now includes the correct column names (KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131) as specified by the Danish Business Authority, ensuring reports can be properly submitted to the regnskab basis system.

This commit changes the danish csv report's header to match with the correct Danish documentation requirements.

The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website.

We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link:

https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis

Based on the documentation chapter 3 & 4, the top row of the csv file (header) should consists of:

KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131

task-id: None

This fix resolves an issue where UK intrastat reports were not displaying detailed line items when users expanded Dispatch/Arrival sections. The system was using an incorrect country code (XU) instead of the proper code (GB) when looking up related transactions, preventing the detailed breakdown from appearing. The fix ensures the correct country code is used so users can now see all relevant transaction details.

The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code.
The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines.
Now, before we build the ID (that we'll use after to fetch children lines), we change the value for the right country code.

no task id

Forward-Port-Of: odoo/enterprise#58620
Forward-Port-Of: odoo/enterprise#58585

This fix corrects how VAT numbers are processed in the Belgian VAT Listing report. Previously, the system incorrectly removed the first two characters from all VAT numbers, which caused errors when VAT numbers didn't start with "BE". The update now uses a proper conversion function to accurately extract the Belgian company registration number from VAT numbers, ensuring accurate reporting.

The aim of this commit is handling correctly the VAT number in the Partner VAT Listing.

Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE.
This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number.

no task id

Forward-Port-Of: odoo/enterprise#58597
Forward-Port-Of: odoo/enterprise#58563

This update fixes an issue in the Online Appointments feature where a custom appointment link was still being generated even after removing all appointment types. The link is now properly removed when no appointment types are selected, ensuring users don't receive broken or invalid appointment links.

Steps to reproduce:
- Install appointment
- Go in calendar -> Online Appointments
- Click on the link button
- Remove the appointment type

Issues:
We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired.

opw-3749154

Forward-Port-Of: odoo/enterprise#58593
Forward-Port-Of: odoo/enterprise#57240

This fix prevents the Knowledge sidebar from breaking when a user loses access to an article they previously marked as a favorite. Previously, the system would try to display inaccessible articles in the sidebar, causing an error that prevented the entire sidebar from loading. Now, the system properly filters out articles the user can no longer access, ensuring the sidebar displays correctly.

-Before this commit:
 When a user lost access to an article which was a favorite, the sidebar was
 provided with the id of the article anyway, resulting in an error when trying
 to access its fields, preventing the sidebar from being displayed at all.

-After this commit:
 Articles ids are not provided to the sidebar when they have a favorite related
 to the current user but that user currently can not access it.

opw-3700698

Forward-Port-Of: odoo/enterprise#55590

This fix resolves an issue where the attendance count displayed on a payslip didn't match the actual number of attendance records shown when clicked. The problem occurred because the system wasn't properly accounting for timezones when comparing attendance dates. The fix ensures consistent counting by using the same timezone-aware logic throughout the payroll system.

Steps to reproduce:
-------------------
- being in Europe/Brussel timezone;
- create a contract based on attendance from 1st to 31st January;
- create two attendancescfot the employee linked to this contract:
    - 5th January from 8am to 4pm for example (A)
    - 31st January from 00:30am to 8:30pm (B)
- create a payslip for the employee from 1st to 30th January;

Issue:
------
The attendance count on the smart button on the payslip and the number of records on the list view (when the smart button is clicked) are not the same.

Cause:
------
The domain that determines attendance uses a condition on the `check_in` field, which is a datetime field, and compares it with a date. For attendance B, we will compare 2024-30-01 23:30:00 with 2024-30-01 23:59:59.

As a result, attendance B will validate this condition.

Solution:
---------
Make this information consistent by using the same logic and taking account of timezones.

Add a method that allows you to retrieve all attendances linked to a payslip. Use this to generate the domain that will select the correct records (based on their id) in the list view.

Note:
-----
`_read_group` manages timezones and therefore
`check_in:day` for attendance B returns 2024-31-01.

opw-3794161

Forward-Port-Of: odoo/enterprise#58431

Fixed an issue where the event submenu selector was hidden when users were viewing certain event pages like event tracks. The submenu is now always accessible on mobile devices, allowing users to easily navigate between different event sections without being restricted by their current page location.

The recent redesign added a separate submenu selection for the mobile view however it was hidden when outside of one of the submenus.

There is no need to do that, and it prevents users from selecting a different submenu when accessing pages such as event tracks.

The submenu selector now takes on a fallback value when outside of one of the selectable submenu.

task-3695979

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

This fix resolves an issue where search bar input fields became invisible when added to website pages. The search input was blending in with the page background due to matching colors and missing borders. The fix adds a new styling option that lets users choose between a light style (for app-like search bars) or the default input style, with the default style automatically applied when adding new search snippets to prevent visibility issues.

Since this commit [1], the two searchbar snippets are broken.

The search bar input seems invisible because it shares the same color as the default snippet background and has no border. This style matches the search inputs used in apps (like the "/shop" search bar), which isn't affected by the "Input fields" settings in the "Theme" tab.

To resolve this issue, this commit introduces a new option to choose between the "light" style (similar to "/shop" search bars) and the "default input style" for the 2 "Search" snippets.

The "default input style" is automatically applied when the "Search" snippet (excluding saved snippets) is dropped to address the issue caused by the light-on-light color scheme.

Steps to Reproduce the Issue:

- While in Website edit mode, drag and drop a "Search" snippet onto the page.
- Bug: The input appears invisible due to the lack of a border and a background color identical to the snippet's section color.

[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20

task-3662985

This fix corrects a display issue where column values were misaligned with their headers when viewing grouped data in list views, particularly in the Planning app. The problem occurred when certain view options were enabled, causing values to shift one column to the right. The fix adjusts how the system calculates column spacing to ensure values always line up correctly with their headers.

Steps to reproduce:
- Install **planning** app.
- Go to **planning** app, and convert the view to **List**.
- Group by **Resource** -for example-.
- Notice how the Allocated Time column values are mis-aligned with the header label.

Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
	- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
	- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
	- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.

The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
	- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
	- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
	- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
	- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
	- both firstAggregateIndex` = `lastAggregateIndex` = -1
	- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1`
	- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.

opw-3764616

Fixed an issue where the system was incorrectly calculating suggested balance amounts when editing journal entry lines. When users deleted or modified lines and added new ones, the system was not properly accounting for all existing lines, resulting in wrong credit suggestions. This fix ensures the system considers all saved line data when computing balances.

Create a new Journal Entry
Add a 100$ debit line 1
Add a 100$ debit line 2
Add a new line: system will suggest 200$ credit line 3
Save
Delete line 3
Change line 2 amount into 50
Create a new line

Issue: the system will compute a credit amount of 50$
This occurs because in the onchange we work with a new record
representing the set of changes
Commands sent by the orm are:
- DELETE of line 3
- UPDATE of line 2
So in the new record we don't have information on line 1.
A solution is to recover the data from the stored record

opw-3757415

Fixed an issue in the Lunch app where users would encounter a technical error (traceback) when running scheduled email tasks with incorrect settings. Now users will see a clear, user-friendly error message instead, making it easier to identify and fix configuration problems.

Steps to reproduce:
-----
1. Have lunch app activated
2. Settings > Technical > Scheduled Actions
3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email.
** Traceback error **

Changes
-------
The user will see an UserError instead of a traceback.

opw-3751229

Forward-Port-Of: odoo/odoo#156706
Forward-Port-Of: odoo/odoo#156440

This update fixes missing translations for numpad buttons and customer editor form fields in the Point of Sale system. Users in non-English languages will now see these interface elements properly translated, improving usability and consistency across the POS application.

Issue
-----
In a POS session, some buttons of the numpad and some fields in the client editor form are not translated.

**opw-3783252
opw-3756593**

This fix ensures that when processing online payments for POS orders, the system correctly uses the customer associated with the POS order instead of defaulting to the logged-in user or a generic public user. This improves payment accuracy and customer record management by properly linking payments to the intended customer.

Before this commit:
POS online payments uses the logged-in user or the public user,
even when a POS order customer might also be present.

After this commit:
We check the partner_id for POS orders and give it
precedence over both the logged-in user and the public user.

task-3805695

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

This fix prevents the Knowledge module from accidentally removing important content from embedded views when multiple users are editing collaboratively. Previously, when one user updated view settings, the system would unnecessarily clean up the entire view content, potentially breaking the display. Now it only cleans the specific setting being changed, preserving all view content and preventing disruptions during collaborative editing sessions.

In Knowledge, embedded views anchors have a `data-behavior-props` attribute
containing information on how to render the embedded view. That attribute is
sometimes updated, and during a collaborative session, receiving such an update
as a collaborative step would trigger a full sanitization of the embedded view,
possibly discarding some transient content that could break the view, even
though it caused no security issue since it is all rendered on a per client
basis (each client fully renders its own view).

The proposed solution is to sanitize only the attribute of the node and not its
content during `_safeSetAttribute`, which is reasonable, because the node
content is already sanitized recursively for `add` mutations.

task-3060490

Forward-Port-Of: odoo/odoo#157202

This update fixes two issues with the karma wheel feature used in courses and user profiles. First, it corrects the visual layout of the karma wheel which was breaking in different languages, especially French, where translated text was too large and overlapped the wheel. Second, it fixes a bug where the system was incorrectly calculating a user's next rank level, showing wrong progress percentages and rank names. These fixes ensure the karma wheel displays properly across all languages and shows accurate user progression information.

How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"

The design of the karma wheel is broken because the translation for "Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k xp pour passer au niveau supérieur"). While in French the text go outside the wheel and it appears clearly broken, it is also the case in English as the rank name is hidden due to the length of the text (for example when gaining one karma: 7.49k is displayed instead of 7.5k which takes more place).

To avoid modifying the template "profile_next_rank_card" that could break community overrides, we solve this problem in css by increasing the karma wheel size and the precentage of width occupied by the text inside the wheel. We also reduce the vertical margin between the rank name and the descriptive text and reduce the line height to avoid the text to overlap with the wheel. And if the text is still too large for some language it will be truncated and an ellipsis will be used.

Technical note: we do the change in website_profile.scss (and not in website_slides.scss) because it applies to both karma wheel: the one on course home page and the one in the profile page.

[FIX] gamification: fix incorrect next rank

How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"

The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be: 4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next level is doctor at 10k).

We solve that issue by fixing the method that determine the next rank (see technical note for more details).

Technical note: the problem occurs because the admin user has the rank 4 but its field next_rank_id is null while there is a level 5. In that condition, the method _get_next_rank returns an empty recordset while it should return the rank 5. We simplify that method to always return a rank if there is one suitable (if you reach the last level, there are no next level).

(Initial PR in saas-16.1: odoo/odoo#151372)

Task-3617054

Forward-Port-Of: odoo/odoo#157585

This fix corrects an issue where theme background images were not displaying properly when the footer "Slide Hover" option was enabled. Previously, only the background color was being applied to the page layout, causing the background image to be ignored. The fix ensures that both background colors and images are correctly displayed when this footer feature is active.

Steps to reproduce:
- Click on the footer and enable footer "Slide Hover" option
- In the theme tab, add a theme bg image
- Drag & drop a "Text - Image" snippet (or any snippet without a bg color set, or any snippet with a bg color set and just remove it)
- The snippets and page layout in genral will receive a forced color instead of using the bg image set.

This is because with the slide hover option, the bg has to be moved from the `#wrapwrap` to the `main`. Indeed, it's the main which is scrolling hover the footer, not the `#wrapwrap`. Without doing that, the elements hover the footer would have a transparent background and would not hide the footer.

But the bg image was not considered when doing it, only the bg color.

opw-3704746

Forward-Port-Of: odoo/odoo#157077

Fixed an issue where the image editing overlay would disappear after cropping an image in website snippets. Users no longer need to click elsewhere and reselect the image to see the overlay again. This improves the image editing experience by keeping the editing interface visible throughout the cropping process.

Steps to reproduce:
 1. Go to the website
 2. Drag a snippet that contains an image
 3. Select the image block
 4. Go to customize the image
 5. Go to transform - select crop image
 6. Crop and apply changes -> Overlay is hidden

Before this commit, after cropping an image the overlay was hidden. To
make the overlay visible again, you have to click elsewhere on the
snippet and then click on the image again, because the overlay was being
hidden.

When we perform an image crop, we activate the `hide_overlay` action,
which subsequently eliminates the `o_we_overlay_preview` class. This is
due to the fact that, during the image-cropping process, the
`previewMode` is set to `false.` However, if we wish to keep the overlay
visible, We can simply avoid triggering the "hide_overlay" action.

task-3392225

Forward-Port-Of: odoo/odoo#127526

Fixed a bug in the website editor where dragging column edges beyond the preview area would continue resizing even after releasing the mouse. The issue occurred because mouse events weren't properly detected outside the preview window. This fix ensures that column resizing stops correctly when the mouse is released, improving the editing experience.

**[FIX] web_editor: fix resize column outside of the iframe**

Steps to reproduce the bug:

- Enter Website edit mode.
- Drag and drop an "Image-Text" snippet onto the page.
- Grab the right edge of the right column of the snippet and extend it
to the right until it overflows the iframe and hovers over the editor
panel.
- Release the mouse, then hover over the iframe again.
- Bug: The "mouseUp" event was not triggered, and the column resizing
still occurs.

This bug occurs because the "mouseUp" event was attached to the
<body> of the iframe and not to the window of the iframe.

Indeed, for mouse events to be triggered outside of an iframe, they need
to be attached to the iframe's window.

This fix is not necessary before the version 16.0. Before V16.0, the
page preview and the options panel shared the same window. It's only
since this commit [1], where we moved the page preview into an iframe,
that the bug occurs.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

taks-3562970

Forward-Port-Of: odoo/odoo#156529

This fix resolves an issue where currency information was not properly displayed when inserting a list view containing both monetary amounts and their corresponding currency fields into a spreadsheet. Depending on the order of columns, either the currency format or currency name would be missing, making financial data incomplete or difficult to interpret.

Get to a list view where there's a monetary field AND the related currency field in the same list.
Then insert the list in a spreadsheet.
=> Either the currency format is not fetched or the currency name, depending on the order in the list.

bug introduced by 8777973e

opw-3770057



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

This fix corrects how payment references are imported from Factur-X formatted invoices. Previously, the system was reading the payment reference from an incorrect field. Now it reads from the same field used when exporting invoices to Factur-X format, ensuring consistency between import and export operations.

When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported.

Description of the issue/feature this PR addresses:

Current behavior before PR:
When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a specific field "PaymentReference" under "SupplyChainTradeTransaction" section.  

Desired behavior after PR is merged:
The imported field is the same as exported.

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

The stock accounting module has been refactored to make ownership tracking more flexible and easier to customize. This change simplifies how the system checks and manages inventory ownership, making it easier for future updates and custom features related to how inventory is valued based on who owns it.

This PR adds a refactoring of the owner_id check within the stock_account module.
The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. This refactoring allows for extending to the functions as needed.

@qrtl

Forward-Port-Of: odoo/odoo#155694