* = ai_knowledge, ai_livechat, test_full_discuss_enterprise

In this commit, we "overhaul" the way that AI messages are rendered. This effort was motivated not just by aesthetics but also to make the AI responses more readable and understandable for users.

The first change was to inject boostrap classes to the tables added by the markdown library. By doing that, we make tables render as tables with borders and highlighting, instead of just text.

We also added the prism library in the modules assets. Now, if the AI replies with some code snippet, it will be highlighted depending on the language used.

We also added different CSS rules in `chat.scss` to changed some of the front end details like the padding and margin between elements in messages. In said file, we also changed some display and width values, to make tables and code segments horizontally scrollable, so information won't get "smushed" in a chat window. We also limit the width to 75% of the AI response in the discuss app because otherwise the information was too spread out - we added a media query to return the width to 100% in smaller screens.

We moved the "Expand in Discuss" button, to be inbetween the close button and the minimise button, because the dropdown was confusing users, who imagined that they can switch between agents directly from the chat window.

We additionally, made it so conversation titles change based on the user's first query, similarly to how it is done in the web versions of ChatGPT or Gemini. For that, we initial create channels with the name field empty and then we extend the display_name compute method of the discuss channel to add the agent's name in case the name is empty. After the first message we populate the name field which should by extension change the display_name field.

We heavily patched the message template to remove the bubble and apply classes for the css rules. We also made it so user messages remain in the right in the discuss app (like in chat windows), increasing visual clarity.

Finally, the test_natural_language_query_tour was modified to check for the new descriptive chat window title feature and the test_create_ai_chat was modified to reflect the new way of creating ai chats - with empty name and populated display_name.

Task-5164382

Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values.

This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state).

This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period.

The following rules/fields are updated to use the version object:
- Tax Treatment Category
- Additional Withholding Amount
- Extra Pay
- TFN Declaration
- Medicare (Reduction, Exemption, and Levy)
- Training Loans
- NAT 3093 Amount (Tax Offset)
- Child Support (Garnishee and Deduction)

A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates.

Task-5002697

Forward-Port-Of: odoo/enterprise#108063
Forward-Port-Of: odoo/enterprise#106550

**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.

**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.

**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.

**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.

opw-5902414

Forward-Port-Of: odoo/odoo#247737

**Steps to reproduce:**
* Install `Accounting` and `accounting_peppol` modules.
* Create Belgium company.
* Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`.
* Create and post a customer invoice.
* Click **Send & Print**.
* Select only **Email** and click **Send** to generate the PDF.
* Click **Send & Print** again.
* Select only **Peppol** (partner configured for Peppol).
* Click **Send**.

**Observed behavior:**
* The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF.
* The receiver gets the XML data without the PDF representation.

**Cause:**
* When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it.
* The PDF embedding into the UBL XML relies on this post-processing step.
* Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic.

**Fix:**
* When sending via **Peppol**, detect if a PDF already exists on the invoice.
* If so, explicitly post-process the UBL XML to embed the existing PDF before sending.
* Ensures the PDF is always included in Peppol messages, regardless of when it was generated.

opw-5495465

Forward-Port-Of: odoo/odoo#245901

Steps to reproduce:
----------------------------------------
1. Install the Recruitment module
2. Navigate to Recruitment > Applications > All Applications
3. Go to Kanban view
4. Make any application Very High Priority (3 star)
5. Refresh the page

Observation:
----------------------------------------
Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage.

Issue:
----------------------------------------
The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41

Solution:
----------------------------------------
Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first

opw-5893371

Forward-Port-Of: odoo/odoo#249712
Forward-Port-Of: odoo/odoo#247779

Currently in saas-19.2 on start of Odoo tim_interface throws an exception and Odoo doesn't start:

```
2026-02-20 14:15:31,683 10276 CRITICAL ? odoo.modules.module: Couldn't load module iot_drivers  2026-02-20 14:15:31,684 10276 ERROR ? odoo.service.server: Failed to load server-wide module `iot_drivers`.  Traceback (most recent call last):
  File "/home/pi/odoo/odoo/service/server.py", line 1554, in load_server_wide_modules     load_openerp_module(m)
    ~~~~~~~~~~~~~~~~~~~^^^
  File "/home/pi/odoo/odoo/modules/module.py", line 488, in load_openerp_module     __import__(qualname)
    ~~~~~~~~~~^^^^^^^^^^
  File "/home/pi/odoo/addons/iot_drivers/__init__.py", line 18, in <module>     interface_thread().start()
    ~~~~~~~~~~~~~~~~^^
  File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/tim_interface.py", line 61, in __init__     self.tim_api.six_initialize_manager.argtypes = [ctypes.c_int]     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'six_initialize_manager'
```

This is due to a missing 'tim' directory:
```
/home/pi/odoo/addons/iot_drivers/iot_handlers/drivers cp: cannot stat '/home/pi/odoo/addons/iot_drivers/iot_handlers/drivers/tim/libtimapi.so.3.38.0-5308': No such file or directory
```

This PR adds 'tim' directory in unzipping fixing the path


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

Steps to reproduce the issue:
=================================

1. Go to Website > Products and edit a product.
2. In the product description, add a header using the editor.
3. You can now drop an image in that place, so drop it.
4. Click on the image and try to add an anchor for it.

-> Traceback

Cause:
======

The reason an image can be dropped in that location is because the editor
added an adjacent element, such as a `<p>` or `<h1>`, which is considered
a valid drop zone by the drop zone plugin. However, when trying to
create a link, the parent element checks if it is valid to have an
anchor, but then when adding an anchor the element text is undefined,
causing a traceback.

Why can an image be dropped in that location after adding the editor?
The bug was due to passing `excludeNearParent` as a property name instead
of `excludeParent` to the `getSelectorSiblings` function, which always
evaluated to false. So it allowed dropping images in invalid locations.

Solution:
=========
Pass the correct property name.

Impact:
=======
This fix enforces the intended dropzone behavior where content snippets
(like images, buttons with `.o_snippet_drop_in_only`) cannot create
dropzones next to elements that are direct children of `.oe_structure`
containers.

Test Changes Required:
=======================
The button tests were failing after the fix because they were testing
buttons as direct children of
`<div id="wrap" class="oe_structure oe_empty">`. This was only working
before due to the bug - `excludeNearParent` was being ignored.

The fix wraps the test buttons in a `<div>` container,
making them children of a child of `.oe_structure` rather than
direct children.

opw-5489444

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

Forward-Port-Of: odoo/odoo#249707
Forward-Port-Of: odoo/odoo#244324

Currently, a user can add a timesheet entry with a negative Hours Spent 
value `exceeding six digits`.

**Steps to reproduce:**
- Install the `timesheet_grid` module.
- Open the `Timesheets` app and click `Add a line`.
- Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000).

**Observation:**
The line is added without any warning, whereas entering a positive 
value with more than six digits correctly raises an `error`.

**Root cause:**
At [1], the constraint validates only positive values exceeding six digits. 
As a result, negative values with more than six digits are not checked 
and bypass the `UserError validation`.

**Fix:**
This commit updates the constraint to ensure the six-digit limit 
applies to both positive and negative values.

[1]:
https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49

opw-5909417

Forward-Port-Of: odoo/enterprise#108182
Forward-Port-Of: odoo/enterprise#106781

Before this commit:
If IoT system clock is wrongly set (happened on a Wi-Fi environment with slow connection). The system clock will abruptly change for a date in the future which will trigger all `schedule` jobs (which will think they are several days late).

In addition to this oversight, on an IoT on which "custom IoT handlers" configuration is enabled, if the `upgrade.check_git_branch` job is called on IoT boot, it will trigger the following traceback:
```py
2026-02-17 13:53:41,751 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-4:
2026-02-17 13:53:41,757 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-02-17 13:53:41,758 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/home/pi/odoo/addons/iot_drivers/tools/helpers.py", line 50, in run
    service.server.restart()
    ~~~~~~~~~~~~~~~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/home/pi/odoo/odoo/service/server.py", line 1622, in restart
    os.kill(server.pid, signal.SIGHUP)
            ^^^^^^^^^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: AttributeError: 'NoneType' object has no attribute 'pid'
```
Which will prevent the IoT to restart thus to load custom handlers

After this commit:
Brutal time changes (of 10 minutes (in a 3-second loop)) are detected, and jobs schedules are updated to prevent misfire calls

Forward-Port-Of: odoo/odoo#249112

### Issue:
Due to this issue, `coupon_ids` which are never used are still shown in loyalty coupons history which is confusing for users.

#### Steps to reproduce:
1- Create two promotions:
   - Promo A: 10% discount
   - Promo B: 20% discount

2- Create a SO and add a line. Then confirm the SO.
3- Click on `Reward` button.
4- A dialog should show both promos. Discard the dialog.
5- Navigate to `Discount and Loyalty`.
6- Open Promo A and B and you can see both have lines with
   `coupon_id.order_id` = `created SO` which is confusing. `Issue 1`
7- Navigate back to SO. Click on `Reward` and select Promo A, apply.
8- Navigate to Promo B. As you see the the `coupon_id` related to
   the SO is still there. `Issue 2`

### Cause and Fix:
This is due to unlinking `coupon_ids` only in SO confirm action, causing this issue on already confirmed SOs:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/sale_loyalty/models/sale_order.py#L132-L136

We can fix this issue by `unlinking` the `coupons_ids` when a reward is applied or the dialog is discarded.

However there are 2 limitations:
1- The view needs to be updated. Otherwise, `coupon_ids` will not be deleted upon clicking on `discard` button. However the fix is still stable.
2- What if the dialog is closed with the cross button or the tab is closed without selecting a reward? In that case the issue will still persist.

To fix these issues, we can show only used `coupon_ids` in `loyalty_coupon_id` list view. However that cannot be done in stable as it requires `use_count` to be stored.
NB: With some complex filters this also could be fixed on stable but not worth it.

opw-5424753

Forward-Port-Of: odoo/odoo#245534

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105368
Forward-Port-Of: odoo/enterprise#100278

## Issue
When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model.

## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a Product P
    - Tracked *By Unique Serial Number*
    - Create a BoM for product P
5. As a user without *Write* access on the `ir.sequence` model:
    - Create and confirm a Manufacturing Order for product P - Quantity >= 2
    - Click *Generate Serial*, *Generate*, *Apply*
6. **An Access Error is displayed, stating that you are not allowed to modify 'Sequence' records.**

## Cause
Commit https://github.com/odoo/odoo/commit/3ff0f2e3ef4f (and https://github.com/odoo/odoo/commit/9cd0c4affeb1) changed the way the serial sequence was updated by replacing `IrSequence.next_by_id()` with manual incrementation (`IrSequence.number_next_actual += 1`). The former method requires read access but does not require write access, whereas the latter does.

https://github.com/odoo/odoo/blob/8f0a5d31d62ea6fc2a1c94be8501735a01323954/odoo/addons/base/models/ir_sequence.py#L272-L275

Since the write access should not be required to generate serial numbers, the sequence is incremented using `sudo()`.

(related to)
opw-5882578

Forward-Port-Of: odoo/odoo#249778
Forward-Port-Of: odoo/odoo#249662

Versions:
---
- 17.0+

Issue:
---
Delivery amount is doubled in stripe express payment checkout.

Steps to reproduce:
---
1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay)
2- Set fixed price on standard delivery: 10
3- Navigate to website: add a product to cart. Use express checkout.

Outcome: The delivery price is calculated twice which is wrong.

Cause:
---
This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount.
Then we add delivery carrier `minorAmount`:
https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice.

Fix:
---
We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines.

opw-5424398

Forward-Port-Of: odoo/odoo#249551
Forward-Port-Of: odoo/odoo#248415

Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order

Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50,  product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250

Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state

Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
    

opw-5609964

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

Forward-Port-Of: odoo/odoo#248184
Forward-Port-Of: odoo/odoo#245400

## Short functional explanation of the error
When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown calendar, the color dot doesn't show. Instead, 'null' appears.

## Reproduction Steps
1. Go to planning and create a shift extended on multiple days for an employee who has a flexible schedule.
2. Click Publish and Send.
3. Click on Actions on the left top side and click Preview.
4. Select the employee you just created the shift for.
5. Click on Preview.
6. It opens a window with the employee's planning. On the left top side, click Month.

### Expected behavior
A shift spread on multiple days should show, with a color dot on the left of the schedule.

### Unexpected behavior
Null appears instead of the color dot. Moreover, the background of the shift has the color of the color dot that should be there.

## Origin of the issue
For employees with specified working schedules, multiple-days shifts are limited to their schedule. Thus, these shifts are split on the working hours of the employee.
But flexible employees have no specified working hours, so the shifts aren't split. This creates multiple day slots. FullCalendar generates different html codes for such slots, which don't contain class ```fc-daygrid-event-dot```, responsible for the creation of the color dot next to the shift schedule. However, even if this color dot isn't created, we still mention it here:
https://github.com/odoo/enterprise/blob/59cec3e8c6a0880178aa93651dca66c367d36841/planning/static/src/js/planning_calendar_front.js#L116 to display shifts. Therefore, we have to create it if it doesn't exist.
__
opw-5437257

Forward-Port-Of: odoo/enterprise#104822

Currently, an error occurs when a user opens the Tax Returns report.

**Steps to Reproduce:**

 - Install the `Accounting` module.
 - Go to `Journal Entries` and create a journal entry with lines, `Ex:`
   - One `Receivable` line with a positive debit.
   - One `Income` line with the same credit.
 - `Post` the journal entry.
 - Go to `Accounting > Closing > Tax Returns`.
 - Set the `date` and click `Apply`.

`AssertionError: Invalid falsy real id`

When opening the Tax Returns report, it going generates the Annual Closing Checklist. During this 
process, it tries to get the unknown partner’s account line ID [1]. However, if the line_id does not 
contain anything related to the target model (account.move.line), the method returns None [2]. Later, 
it attempts to browse using this None value which raise the error [3].

This commit ensures that only valid ids are added, preventing None values from being browsed.

[1]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2365-L2371

[2]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_report.py#L2461

[3]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2399

sentry-7263718845

Steps to reproduce the issue:
=================================

1. Go to Website > Products and edit a product.
2. In the product description, add a header using the editor.
3. You can now drop an image in that place, so drop it.
4. Click on the image and try to add an anchor for it.

-> Traceback

Cause:
======

The reason an image can be dropped in that location is because the editor
added an adjacent element, such as a `<p>` or `<h1>`, which is considered
a valid drop zone by the drop zone plugin. However, when trying to
create a link, the parent element checks if it is valid to have an
anchor, but then when adding an anchor the element text is undefined,
causing a traceback.

Why can an image be dropped in that location after adding the editor?
The bug was due to passing `excludeNearParent` as a property name instead
of `excludeParent` to the `getSelectorSiblings` function, which always
evaluated to false. So it allowed dropping images in invalid locations.

Solution:
=========
Pass the correct property name.

Impact:
=======
This fix enforces the intended dropzone behavior where content snippets
(like images, buttons with `.o_snippet_drop_in_only`) cannot create
dropzones next to elements that are direct children of `.oe_structure`
containers.

Test Changes Required:
=======================
The button tests were failing after the fix because they were testing
buttons as direct children of
`<div id="wrap" class="oe_structure oe_empty">`. This was only working
before due to the bug - `excludeNearParent` was being ignored.

The fix wraps the test buttons in a `<div>` container,
making them children of a child of `.oe_structure` rather than
direct children.

opw-5489444

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

Forward-Port-Of: odoo/odoo#249707
Forward-Port-Of: odoo/odoo#244324

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

Currently when event only have questions of type text, the field `registration_answer_ids` is empty after the order is synced to the backend.

Steps to reproduce:
-------------------
* Create an event for which you anloy have questions of type text: name, phone, email
* Open a shop
* Sell a ticket for the event and answer all 3 questions
* Validate order
* Check event registrations
> Observe that although attendee's corresponding fields have been populated,
the question' list is empty.

Why is the issue happening:
---------------------------
In the model EventRegistration there are two fields `registration_answer_ids` and `registration_answer_choice_ids`. Those two fields share the same relation table.
https://github.com/odoo/odoo/blob/7c93b869a97f30a5b75d603b5973bf37b91bd63e/addons/event/models/event_registration.py#L83-L84

The registration is created here:
https://github.com/odoo/odoo/blob/ef92cf5b33a3e55e801feea71bdbdd212da59adb/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L246 For context, when calling the create method `registration_answer_ids` has 3 values and `registration_answer_choice_ids` is empty (since no selection question).

During the creation process we call the `_update` function. We first see what's happening with `registration_answer_ids`. Since there are some values we'll use the `create` part.
https://github.com/odoo/odoo/blob/ef92cf5b33a3e55e801feea71bdbdd212da59adb/addons/point_of_sale/static/src/app/models/related_models/index.js#L394-L398

The `_connect` method will call itself on the inverse of the field. https://github.com/odoo/odoo/blob/ef92cf5b33a3e55e801feea71bdbdd212da59adb/addons/point_of_sale/static/src/app/models/related_models/index.js#L684

We'll finally try to get the inverse of this inverse. The first problem can be seen here because the inverse of the inverse points toward `registration_answer_choice_ids`.

When we look at the field `registration_answer_choice_ids` since it is empty it will use the `clear` method. This also end up calling the `_connect` method on its inverse. Since the inverse of the inverse of `registration_answer_choice_ids` also points out to `registration_answer_choice_ids` thus it deletes the records that were added with `registration_answer_ids`

This all happens because in the inversMap bot fields point toward the same value but the inverse of this value can only point to one value. In this case, ´registration_answer_choice_ids`.

Why the fix:
------------
Touching the inverseMap or the related model is too risky at this point. So instead we focus on avoiding to clear all records. This can be achieved by creating the record empty of the two fields and creating the records for `registration_answer_ids` and `registration_answer_choice_ids` separately to link them later.

opw-58966712

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

Forward-Port-Of: odoo/odoo#249190
Forward-Port-Of: odoo/odoo#243812

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

# Steps to reproduce
- Open Timesheets
- Go to list view
- Refresh page
- Total is formatted as regular float instead of time

# Cause of the issue
The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget.

Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`).

We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh.

task-5907954

Forward-Port-Of: odoo/enterprise#107203
Forward-Port-Of: odoo/enterprise#107006

According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit.

- The next rules are zeroed out when the gross salary is equal or less  than the minimum wage:
  - IMSS_EMPLOYEE: IMSS Total (Employee)
  - ISR: ISR (Income Tax)
  - SUBSIDY: Used Subsidy
- IMSS_EMPLOYEE and ISR are omitted from the generated XML.
- As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed.
- The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0.

This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage.

target: 19.0
task-5226971

Forward-Port-Of: odoo/enterprise#104668

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

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

----
*Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.*

Forward-Port-Of: odoo/enterprise#107677

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105368
Forward-Port-Of: odoo/enterprise#100278

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#219081