How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#102299
Forward-Port-Of: odoo/enterprise#93034

**Step to reproduce:**
- configure pos for global discount from settings
- start pos
- select product A and add a discount line (product A must have a cost price)
- confirm it.
- refund the same order.
- go to backend and open refunded order from `orders` menu

**Observation:**
- the margin percentage is > 100

**Cause:**
- After  https://github.com/odoo/odoo/commit/9538698f13d5763b49b00f4c06a1a2afc0d6b39e it has been decided to keep order sign regardless if it is refund
or normal order

**Fix:**
- Adapt `_compute_margin` to include signs based on order is refund or not

**Before**
<img width="1151" height="228" alt="image" src="https://github.com/user-attachments/assets/2a1760ad-7ad8-4b64-9d22-cf7cff98c90d" />

<img width="1144" height="198" alt="image" src="https://github.com/user-attachments/assets/8d2d4aff-1293-4906-b79b-518ca22317db" />

After
<img width="1144" height="253" alt="image" src="https://github.com/user-attachments/assets/ec1d4add-d93b-4490-86ad-f5f5d24de9c2" />

<img width="1170" height="244" alt="image" src="https://github.com/user-attachments/assets/c3ce5b6e-a572-4f85-9bf2-f651574ce124" />


opw-5362912


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

Forward-Port-Of: odoo/odoo#238093

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

For the `Türkiye` localization, sending an invoice by email with a recipient bank causes an error.

Steps to reproduce:
1) Install `accountant` and `l10n_tr_nilvera_einvoice` modules with demo data. 
2) Switch to TR Company.
3) Create a customer with country set to `Türkiye`.
4) Open the TR company contact and on the Accounting page edit an existing bank
   account, add a new bank (e.g., 'Test-Bank'), and set `Send Money` to
   `Trusted`.
5) Create an invoice for the customer, confirm it, and send it by email.

ref video: https://drive.google.com/file/d/1OoUzJ-Dr2uuy4yk9P-CKUS0L6OSgeyJ3/view?usp=sharing

Error:
KeyError: 'country_id'

Root Cause:
When sending the invoice, the system generates the invoice XML. In the method `_get_address_node` (see [1]), there is a special case to determine the correct country for `res.bank`. However, when `vals['partner']` is a `res.bank` record, no `model` is provided in `vals`, so it defaults to `res.partner`. The code then attempts to access `partner['country_id']`, which does not exist on `res.bank`, raising the error.

FIX:
Ensure the `model` is set to `res.bank` when `vals['partner']` is a `res.bank` record, ensuring the correct country value is used.

[1]- https://github.com/odoo/odoo/blob/0190bb7faca1dd5ce38dfdacbb8fa446f06d59a3/addons/l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py#L165-L181

opw-5103598

Forward-Port-Of: odoo/odoo#240715
Forward-Port-Of: odoo/odoo#239218

Step to reproduce:
- start pos and finalize a order with product A
- go backend
- Archive product A
- start the pos again
- try to refund the order

Observation:
- Blank page with traceback in console

```
Caused by: TypeError: Cannot read properties of undefined (reading 'filter')
at __exports.getOrderChanges
at Proxy.getOrderChanges
```


Cause:
- until now `product.template` model is looked for filter after a reload
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295
 and not `product.product`, this makes `product_id` available but 
`product_tmpl_id` undefined, causing inconsistency

Fix:
- we add `product.product` in `cleanupModels` for data to in sync with backend 

opw-5237961

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

Forward-Port-Of: odoo/odoo#240424
Forward-Port-Of: odoo/odoo#238514

The link between purchase order and a repair order break at when the PO is confirmed.

### Steps to reproduce:
* Install the Repair and Purchase modules
* Activate multi-steps routes
* Unarchive the MTO route
* Create a product with the MTO route enabled
* Create a Repair
* On the Repair Order, in part add:
	- type : ADD
	- product : mto product
* Save the RO
* Go to Purchase Order
* Confirm the PO
-> Issue Smart link between PO and RO broken.

### Observation:
The smart link is defined on:
RO -> PO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17

When we confirm the PO, from the picking information it will create new moves:
https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298

To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365

### Origin:
In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5:
"`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`."
This breaks the link between PO <-> RO to maybe merge the move in the future.

This issue is not present in 19.0 since it was solve in this commit :
https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a

### About the fix:
The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location.

opw-5121816

Forward-Port-Of: odoo/odoo#237996
Forward-Port-Of: odoo/odoo#232999

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

Steps to reproduce:
=======
1. Go to /shop in edit mode.
2. Change the Product Design.
3. Switch to the "Blocks" tab (so the "Style" tab is not visible).
4. Click on "Save".

Before this commit:
======
The selected Product Design was not saved.

After this commit:
======
The Product Design is now always saved correctly, even if the `ProductsDesignPanel` component has been unmounted.

Technical reason:
=======
The save behavior depended on whether the
`ProductsDesignPanel` component was still mounted at the moment of saving. If it was not alive, changes were lost.

Solution:
=====
We no longer depend on the component being alive. When the Product Design or the Gap is modified, we mark the product list with the `o_dirty_product_design_list` class. On save, we look for elements with this class, retrieve their modified data, and apply the changes.

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

Forward-Port-Of: odoo/odoo#238851

Steps to reproduce:
1- Create new appraisal
2- Confirm appraisal
3- Edit employee and manager feedbacks
4- Set the final rating for the appraisal
5- Mark appraisal as done
6- Reopen appraisal

Issue:
The feedbacks of both the employee and manager are reset to the default template. They should be unchanged.

Cause:
Both the reopen and reset buttons used to call the the same action "action_back" which would set the state of the appraisal to "1_new", there is a compute that is triggered by the change in state which updates the appraisal's department_id which in turn triggers two other computes for the employee and manager feedbacks, those computes have a condition that if the state of the appraisal is '1_new', then the feedbacks should be reset to the templates.

Fix:
Make each button call its own action and make the reopen action set the state to '2_pending' instead of '1_new'. Furthermore make the reset action also reset the final rating for the appraisal.

Task-5411661

Forward-Port-Of: odoo/enterprise#102021

Two related overlay reposition issues are solved separately out of iframe and in the iframe.

**Commit 1:**
[FIX] html_editor: avoid wrong range after insert and popover reposition

Before this commit: The link popover is repositioned at the beginning of the
text when editing url. When insert, we first delete the non-collapsed selection,
then we split the text node by splitTextNode at the collapsed selection. However,
splitTextNode resets the text node's value by its substring, which breaks the
range of the collapsed selection. This range is stored and used to reposition
the overlay when the selection is not in the editable.

Reproduction:
1. selection some text, create a link
2. go the the url field and type something
3. the popover is replaced to the beginning of the text.

After this commit: we use dom function splitText to split the text only when we
need to, e.g. when the currently selection's offset isn't at the beginning or
the end of the text node. The dom function keeps the range properly maintained
after splitting.

However, there is a limitation case from how we create the link on selection,
how the browser manages the selection's range and how the overlay reacts to it.

The limitation case is when the selection is inside one text node and selecting
the whole text node of the range's startContainer (which is the same with
endContainer). When the link is created, we do extractContent on the selection's
range, put it in the link and insert the link at the collapsed selection. During
this process, the browser loses the range's start/end container which leads to
invalid start/end container.

For this range isn't valid case, it triggers the overlay plugin's special
handler which inserts one shadow caret (which is after the inserted link) and
uses it to calculate the position. Because the shadow caret is inserted by the
cloned collapsed range, we can't really have enough context from the range
(about where to re-place the caret) to manipulate the position.


**Commit2:**
[FIX] html_editor: pass selection data to overlay to avoid reposition in iframe

Before this commit: the overlay plugin uses the editable's document's selection
to check if the current selection is in the editable. It works when there's no
iframe, as the overlays are part of the document. However in an iframe's
editable zone, e.g. the website editing zone, the overlays are not under the
iframe document but under the outer window's document. When checking iframe
document's selection, it cannot detect the selection in the overlay, which gives
a wrong "inEditable" value.

After this commit: we pass the getSelectionData to the overlay so it can use the
existing currentSelectionIsInEditable

task-5184799


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

Forward-Port-Of: odoo/odoo#240796
Forward-Port-Of: odoo/odoo#237759

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

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

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102532
Forward-Port-Of: odoo/enterprise#102219

Steps to reproduce:
- Open the VoIP softphone on a mobile device
- Enter a number
- Place the cursor in the middle of the number
- Tap on the *odoo* backspace button
=> The character before the cursor is removed but then the cursor jumps
   to the end of the input.

Note: this also happens when trying to add a number in the middle of
the typed number, using the softphone buttons, but this message focuses
the explanation on the backspace button.

Commit [1] introduced the bug while revamping VoIP and its keypad.
Before that commit, there was a simple `t-on-click` defined on that
backspace button. After the update, that `t-on-click` is still there but
alongside a weird `t-on-touchend.prevent="(ev) => ev.target.click()"`,
which is actually there to prevent zoom-in behavior on double-tap,
although, retesting it does not seem necessary (at least on Android).
In any case, this is the original cause of the bug.
Since [2], the keypad input is using the mail's `useSelection` hook,
which, among other things, manages what happens on click outside of the
input. Before [1], this happened when clicking on the backspace button:

1. The click is handled during its *capture* phase by the `useSelection`
   hook. It checks if clicked location should be considered, the answer
   is yes.

2. The next part of the handler is done in the next microtask (as the
   check is done asynchronously (?? that looks like a bad idea, but
   that's another issue)).

3. That "in the next microtask" part occurs before the event starts
   bubbling: the capture handler saves the cursor position as being at
   the end of the input (?? not sure why, but that's another issue).

4. The click is handled during its *bubbling* phase by the backspace
   button's `t-on-click`, which removes the character before the cursor,
   and sets the cursor position accordingly for the `useSelection` hook.
   The actual cursor position is untouched since [3] on mobile "because
   otherwise it would open the mobile keyboard", but there are other
   ways that would have prevented that I think... to confirm later for
   master via task-5366961 (this actually causes issues in HOOT tests
   but that's another issue).

5. The dialer/numpad component handles the input's focus/cursor. For
   that, it forces a focus and ask the `useSelection` hook to "restore
   the selection", which "restores" it to what step (4) asked.

After [1], this changed to:

1'. Same as step (1)

2'. Same as step (2)

3'. As the click was simulated instead of being the "natural" one
    triggered by the browser touchend handling, the `t-on-click` handler
    is called now, before the "in the next microtask" part of the
    capture handler is done. That means what step (4) did happens now.

4'. Now what step (3) did happens now.

5'. Same as step (5)... but since step (3) and (4) were basically
    swapped, the cursor is now restored as the way it was last saved:
    at the end of the input (again don't know why step the
    `useSelection` hook would want to save it like that though).

There are multiple solutions to fix this:
A. Remove the `t-on-touchend` handler, letting the browser do what it
   naturally does. Although, it might be needed to prevent the mentioned
   zoom behaviors on some phones?
B. Review why the `useSelection` hook wants to save the cursor at the
   end of the input on external click, the point is valid but I am not
   sure that should be this hook's job to enforce it.
C. Review why the `useSelection` hook wants to check if the click has to
   be considered asynchronously, there should be a better way.
D. Configure the `useSelection` hook to consider a click on the
   backspace button as to be ignored, as handled manually by its own
   handlers anyway.

Option (A) should probably be done, by confirming zoom behaviors can be
prevented another way, but it cannot be done in stable anyway. The (B)
and (C) options should be investigated but would also not be stable to
change; also that would modify an exposed hook's behavior so more risky.
Option (D) can probably be done either way and is targeted on fixing the
bug described only, so this is the solution this commit went for.
In master, option (A) will be investigated in the forward-ported version
of this fix.

However... the bug was actually solved 3 months after [1], at [4] thanks
to secret option (E): not removing the `t-on-touchend` but changing it
entirely to call the same handler as the `t-on-click` one. A bit more
stable than option (A) but still not stable.
However... that solution (E) was broken 1 month later, again, by commit
[5] which destroyed step (5) while fixing an unrelated bug. Without that
step, the input cursor is not repositioned after OWL changes the value,
and by default OWL places it back at the end.

The solution is to restore step (5): the problem was that we were
checking if the user was not typing in another input before re-focusing
the keypad input... but the code considered the keypad input itself as
"another input". This commit still adds solution (D) on top of fixing
that, for good measures.

Note that in 19.0+, there is at least another cursor-related bugs,
related to commit [6]. It will be fixed in the forward-port of this one
as they need each other's fix to both work. Really there should be
better ways to handle that cursor position in OWL... might be done in a
future refactoring.

This commit adds a test to hopefully keep the bug fixed, as inspired by
commit [7].

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[2]: https://github.com/odoo/enterprise/commit/2e8f18801156a8069e26fb3d61d4f8d84893e891
[3]: https://github.com/odoo/odoo/commit/adc5448adf863b99b9b2be29985e560f5c12dbd4
[4]: https://github.com/odoo/enterprise/commit/668467678312632b5b9ecf234280690151bf3078
[5]: https://github.com/odoo/enterprise/commit/db82135fd73d5077fc26be7206105192a845c2bc
[6]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
[7]: https://github.com/odoo/enterprise/commit/613ef7332b0d21e947871e9d33b68d069f1412c2

Related to task-5366961

Forward-Port-Of: odoo/enterprise#101856

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages,
but the server correctly rejects their unpin requests. This creates confusion
and a poor user experience where external users see functionality that doesn't
work for them.

**Current behavior before PR:**
----------------------------------------------
- Guest users see the unpin button on pinned messages
- Clicking the unpin button results in server rejection
- UI shows functionality that guest users cannot actually use

**Desired behavior after PR is merged:**
----------------------------------------------
- Guest users cannot see the unpin button on pinned messages
- Internal users continue to have full pin/unpin functionality
- UI accurately reflects user permissions and capabilities
- Better user experience with appropriate access control

Task-5033295

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

Forward-Port-Of: odoo/odoo#240763
Forward-Port-Of: odoo/odoo#229211

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

**Steps to reproduce**
On a local DB, with demo data:
- Change your machine's time to a late part of the day (e.g. 6pm)
- Install `mrp_workorder`
- Set the "Standard 40 hours/week" (used by a workcenter) as flexible.
- From the Shop Floor, start the "WH/MO/00003 - Manual Assembly"
workorder.

"Validation Error: The start date of the time off must be earlier than
the end date."

**Cause**
`_calculate_date_finished` in mrp is calling `plan_hours` and under
certain conditions with a flexible resource, it is possible for
`plan_hours` to return a datetime before the `day_dt` parameter.
This happens because for flexible resources,
`_attendance_intervals_batch` can return attendance intervals with
start or end datetimes outside of the start_dt -> end_dt window.
For example, a flexible calendar with 8h/day will return the
8:00->16:00 interval, even if start_dt is later than 8:00.

**Change**
Don't return attendance intervals outside of the [start_dt, end_dt]
interval by shifting them if necessary.

opw-5123230

Forward-Port-Of: odoo/odoo#233169

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

Following https://github.com/odoo/enterprise/pull/96974, we are doing the filtering of rows much later which shows a lot more areas to improve.

First 2 optimizations can be done for *every* report:
<img width="1920" height="296" alt="image" src="https://github.com/user-attachments/assets/6d7e57ce-8b57-4f1c-9ab7-6212495993d3" />
The (1) optimization is to remove the second safe_eval I forgot to remove before :sweat: 
The (2) optimization consist to hash less keys as well as to not iterate over all the lines in _build_lines_columns

Another 2 smaller optimizations are possible on the general ledger:
<img width="1919" height="362" alt="image" src="https://github.com/user-attachments/assets/61d012ee-1014-4d95-82f7-22b0d9c06500" />
<img width="1919" height="426" alt="image" src="https://github.com/user-attachments/assets/eb7e756c-6d3e-4d6b-a445-e0a28aca553c" />
The (3) is outdated
The (4) is `self.env.company.currency_id.id` being accessed

<img width="1919" height="384" alt="image" src="https://github.com/user-attachments/assets/7b945f64-88ac-4ca5-8552-50bdfe17e849" />
(1) is down from 55.42s to 489ms  

(2) is down from ~26s to ~0.55s    
(4) is down from ~4.14s to ~1.9s

*Tests were done on a demo db populated on models res.partner,account.move with a factor of 20000 and opening the Tax Received line of the general ledger which contained about 150,000 lines and a limit_to_load at the default 80*

Forward-Port-Of: odoo/enterprise#102519

Commit 8f3e242e197b2f26982749 added an Etag to reduce the load on the network when loading a spreadsheet.

Now, this commit ensures the Etag is computed as fast as possible to also reduce the load on the server.

The Etag is based on the latest revision (field `current_revision_uuid`). When computing `current_revision_uuid`, we look at the lastest revisions. However, the current code only look at *active* revisions, and fallback on the snapshot.
The snapshot is a json file (potentially large) that needs be parsed. This is not fast.

To make it worse: spreadsheets are snapshotted as often as it can be, which means we almost always fall in the slow path when computing the Etag.

With this commit, we consider all revisions (active or not). We also load in memory only the latest instead of fetching multiple revisions for each spreadsheet (the work is done by postgres through `_read_group`)

On a spreadsheet with a snapshot of 9.8MB, server time
`"GET /spreadsheet/data/documents.document/17 HTTP/1.1" 304`

before: ~310ms
after:    ~5ms


Task-5431940

Forward-Port-Of: odoo/enterprise#102556

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

*: stock_barcode

Before this commit:
=======================
When accessing a manufacturing order via Barcode in `dark mode`, the producing bar of the finished product is difficult to read due to poor colour contrast.

Steps to reproduce:
=======================
1. Install the `mrp` module.
2. Switch to dark mode.
3. Open any manufacturing order using Barcode.
4. Observe the producing bar for the finished product.

- The text on the producing bar is hard to read because the colour of text does not provide sufficient contrast.

- Additionally, for products tracked by `lot or serial number`,  when the same product is added multiple times, the barcode view groups these entries into a single grouped line, causing the same visibility issue in both MO and normal `picking/transfer` operations.

Cause of the Issue:
=======================
In dark mode, both the text and background colour of the producing bar are light, resulting in low colour contrast and making the text difficult to read. Additionally, the `text-muted` class applied to the `units of measure (UoM)` further reduces readability.

After this commit:
=======================
Updated the text colour of producing bar and background colour of grouped lines to use a darker shade for better visibility in dark mode. Also, removed the `text-muted` class used on `UOM` to improve redability.

TaskID-5117608

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

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

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102532
Forward-Port-Of: odoo/enterprise#102219

Before this commit, when the user starts another timer from another company, the existing timer should be stopped before starting a new one. However, if industry_fsm module is installed and the previous timer is running from another company, the user could have an Access Error because he cannot read the task/ticket linked to the timesheet with the timer to stop.

This commit makes sure the timer is correctly stopped without any issue even if the record linked is inside another company.

Steps to reproduce the issue:
============================
1. Install industry_fsm module
2. Create a task from a timesheetable project and start a timer from that new task.
3. Create a new company and go inside that company
4. Create a new timesheetable project and a new task inside it
5. Start a new timer from that new task.

Expected Behavior:
-----------------
The timer form the first task created should be stopped and a timer for the newest task should be running.

Actual Behavior:
---------------
An access error is raised because the user cannot access to the task linked to the timer to stop.

task-5076633

The thread action 'view-contact' is somewhat like 'livechat-info', in that this action redirects to relevant info to the whatsapp user and livechat-info is a panel with all info on the visitor and more.

The position of both buttons were the total opposite in discuss app:
- 'livechat-info' was put as the 1st panel one before panels
- 'view-contact' was dead last.

There are differences, with 'livechat-info' being a panel and 'view-contact' a redirect button. However, each are important buttons for the type of conversation that justify them being in their own group right now. Since the buttons are mutually exclusive by the channel type, there's reason to have them share the same position.

This commit moves the position of 'view-contact' in discuss header thread actions to be the same as 'livechat-info', that is as the 1st action in the list. This makes its position consistent with livechat info, thus agents of live chat and whatsapp would appreciate the 2 button placement being consistent.

Task-5431313

<img width="1760" height="231" alt="Screenshot 2025-12-18 at 21 02 24" src="https://github.com/user-attachments/assets/ee2baf91-0d9a-49ca-91ac-a7781b33e57b" />

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

…me tokens greedily

Fixes issue #241004

Description of the issue/feature this PR addresses:

This is a hard to reproduce bug becase it depends in what order the set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this:

The _check_formula in this module iterates over tokens to check if the formula only includes allowed tokens or numbers. This check passes when the set is iterated in a way that the token '>=' appears before the '>' token. But if it is the other way around, the check fails.

This is because the way the tokens are consumed in the for; if the '>' is before the '>=', the '>' token will be consumed, the position will be advance one position forward and the next character found will be just the '=' character. This is not an allowed token and the check fails.

The way to solve this is to sort the set by length of the token, from longest to shortest. This assures a greedy consumption of token, which is what is needed to avoid this bug.

Current behavior before PR:
The _check_formula randomly marks a correct formula as malformed

Desired behavior after PR is merged:
Using >= or <= should never cause a formula to be marked as malformed



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

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

Behavior before:
Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the
gross paid for certain vendors. Some payment lines were excluded from the SQL query,
leading to discrepancies in the report.

Behavior after:
The SQL query has been updated to include all relevant payment lines, including those in
asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the
TPAR report to be exported without errors.

Root Cause:
The previous query only considered asset_current and liability_current accounts, ignoring
asset_cash accounts. This omission caused the gross paid amount to be understated relative to
the total GST paid.

Steps to Reproduce:

1. Create a vendor bill.

2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal).

3. Create a bank statement line for the bill amount.

4. Validate the statement line with the corresponding invoice line.

5. Generate the TPAR report — the payment amount should now be correctly included.

OPW: 5148697

Forward-Port-Of: odoo/enterprise#99874