In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit protected document (mainly folder at the company root). That was an error as even if the user has "edit" access (which is ensured in that method), the document can still be protected and the form to edit it should be in readonly then. We ensure here that the form in the details panel is in readonly in that case.

How to reproduce:
- log as demo and go to Document
- Click on Inbox folder
- Open details panel
- Change for example the contact of the document
You get an error while you shouldn't be able to edit it (as the folder is protected).

Technical note: we re-add the condition in the method userPermissionViewOnly:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY")
that we slightly modify to limit the protected document to folder only:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY"
&& this.record.data?.type === "folder")

Task-5881531

Forward-Port-Of: odoo/enterprise#116709

__
## Short functional explanation of the error
When creating a Purchase Order. We add a line containing a product
that has an analytic distribution. After setting a project on this PO,
when we add another line containing the same product, the analytic
distribution of the product isn't added anymore, only leaving it with
the analytic distribution of the project.

## Reproduction Steps
1. Go to settings and enable Analytic Accounting.
2. Go to Accounting > Configuration > Analytic Distribution model.
Create a model with a product (prd) you remember, and add an analytic
distribution (ad).
3. Go to Project. On a given project (p), select the Hamburger menu and
click Settings. Then, in the Settings tab, under Analytic, make sure
the Project field is filled.
4. Create a new Purchase Order. Select a vendor and add a line with the
product (prd). On the top right of the Form, click on the view button
and select Analytic Distribution to show it on the form.
There, we should see the product (prd) with its corresponding Analytic
Distribution (ad) on the form.
5. Click on the Other Information tab and select the project (p).
Click on the Product tab. There, under Analytic Distribution field,
you should see (ad) and the Analytic Distribution of the project (p).
6. Click on save and add another line with the exact same product.


### Expected behavior
Under Analytic Distribution, we should see (ad) and the Analytic
Distribution of the project (p), as for the first order line

### Unexpected behavior
Under Analytic Distribution, we only see the Analytic  Distribution of
 the project (p).


## Origin of the issue
When we add another line, we trigger the compute method of the
Analytic Distribution. However, due to this piece of code:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14
when we create a new order line, we never compute its analytic
distribution: `self` will contain only `project_lines`, and
`empty_project_lines` is empty as well. Therefore, we call the super
 method with nothing, so when we get in the
super method:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259
we never compute the analytic distribution of the newly created line.

This piece of code was added in this commit:
https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae
to fix the issue that when a user enters manually an analytic
distribution, this entry will be lost when triggering the compute of
the analytic distribution.

However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic 
distribution, as it is much harder to add it again after its removal. 
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.
__
opw-6063418

Forward-Port-Of: odoo/odoo#257558

## The Problem
During the initialization of `stock_account`, the logic creating `product.value` instances triggered cache misses on `product.product`, accessing fields (`company_id` and `standard_price`) inside `_create_product_value`, and field `uom_id` inside `_run_fifo_get_stack`. Due to prefetching, this loaded all product data into memory, causing significant memory usage on large databases.

## The Solution
Disabled prefetching in the full flow.

Didn't go with fetching only the needed fields instead of disabling for two main reasons:
- Field `standard_price` accessed in the loop is company dependent, so it needs to be fetched inside, which would be a bit verbose.
- Fetching `company_id` outside the loop, `standard_price` inside the loop, and `uom_id` which is accessed down the stack in the `.create` call on `product.value` won't be an explicit/robust solution for the long term.

---

## Benchmarks
*Tested on a SaaS database with 500k products:*

| | Before | After | Note |
| :--- | :--- | :--- |  :--- |
| **Memory** | 3.6GB | 1.6GB | **-55%** (fits in memory limit) |
| **Time** | 10m | 11m | **+10%** (acceptable tradeoff) |

**OPW-6173153**

Forward-Port-Of: odoo/odoo#262702

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263593
Forward-Port-Of: odoo/odoo#256693

**Steps to reproduce:**

Problem A)
- create a storable product avco perpetual
- add 2 unit in stock and set a cost of 10
- set the invoicing policy as "delivered quantities"
- create and confirm a SO for 2 quantities
- validate the delivery
- click on "Create Invoice" and confirm the invoice
- from the delivery, create and validate a return for 1 unit.
- from the product form, change the cost to 15
- from the sale order, click on "Create Invoice"
- confirm the Credit Note

Problem B)
- create a storable product with fifo perpetual
- confirm a PO for 1 unit at 10 and validate receive
- confirm a PO for 1 unit at 20 and validate receive
- confirm a PO for 1 unit at 60 and validate receive
- create a SO for 3 unit
- deliver 1 unit with backorder
- deliver another unit with backorder
- deliver the last unit
- create and confirm invoice
- return the second delivery
- from the invoice click on 'credit note' and validate
the credit note with a quantity of 1

**Current behavior:**

Problem A)
the cogs is 25

Problem B)
the cogs is 30

**Expected behavior:**

Problem A)
it should be 10

Problem B)
the cogs should be 20 cause the move returned
had a value of 20

**Cause of the issue:**
Inside \_get\_cogs_value(), if there is an original invoice
linked to the credit note we take the unit_price from this invoice.
But, if the credit note is not created from the invoice (via the
Credit Note button) but via the sale order (via create invoices),
the account\_move has no reverse\_entry_id so we won't
use the price_unit from the original line.
https://github.com/odoo/odoo/blob/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/stock_account/models/account_move_line.py#L56-L58
So basically what we do for now is:
If the credit note was created from invoice we use
the unit price from original invoice in all cases.
If the credit note was created from sale order we
use get\_price\_unit in all cases (which will work for
fifo because we'll use the value of the returned
move but fail for avco if the standard price has
changed cause we use the standard price)
https://github.com/odoo/odoo/blob/dccd2256660b1e211707b740074f5fbba95ae149/addons/stock_account/models/stock_move.py#L261-L265

**Fix:**
Regardless of how the credit note is created, if
it's fifo we use get\_price\_unit to adapt to the value
of the moves, if not we use the unit_price from
original invoice

opw-6097090

Forward-Port-Of: odoo/odoo#259630

We do not need this extra aggregate expression.

The purpose of this aggregate expression is only
to invert the sign of the computation returned by
the expression account_tax_report_payg_w2_tag. Instead of doing the sign inversion through a separate aggregate expression, we can directly include the negative (-) sign in account_tax_report_payg_w2_tag itself, as already done in the new report expressions.
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/l10n_au/data/bas_a.xml#L386 https://github.com/odoo/odoo/commit/2c9ab8e77db7aa127a259f7f3e06ecfed94252ab

Why is this fix needed?

This aggregate expression creates issues during the tax_to_invert upgrade process. Since the sign conversion is handled through a separate expression, the upgrade query is unable to correctly identify the actual expression sign, which leads to incorrect computations during migration.

Related PR: https://github.com/odoo/upgrade/pull/10162

- OPW: 6097598

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

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116794
Forward-Port-Of: odoo/enterprise#113804

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#263114
Forward-Port-Of: odoo/odoo#257342

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#112578

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

## Issues
When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when opening the *Timesheets* tab,
the timer resets to 00:00, and if the timer was started more than a minute earlier, it begins counting down (00:00, then -00:59, and so on). (**I1**)

A second issue (**I2**), introduced at the same time, is that two timers can run simultaneously if the database is reloaded while a timer is active.

A third issue (**I3**) happens after starting and stopping a timer from the Project app: the timer seems to still be running in the Timesheet app.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Create a Project P and a Task T
3. Start the timer for Task T, wait a few seconds, then open the *Timesheets* tab
4. **The timer from the _Timesheets_ tab does not match the one on top of the page**
5. Wait for the timer in the header to reach 00:01:00, then open the *Timesheets* tab again
6. **The timer is going backward**

For the second issue (**I2**), after executing the steps above:
7. Do not stop the timer, but stop the database and start it again
8. Create a new Project P2 and a Task T2
9. Start the timer for Task T2
10. **The timer in the header blinks between the timer from T1 and the newly started timer for T2**

![5879176](https://github.com/user-attachments/assets/d9be8b8c-8973-4790-80a5-6f291f0b766a)

For the third issue (**I3**):
1. In the project app, (create a project and a task and) start then stop a timer. Log the time
2. Open the timesheet app
3. **A timer is running**

## Cause
The issues are introduced by the following commit: https://github.com/odoo/enterprise/commit/f4c7115fdf.
The commit aimed to resolve an issue in which timers for sample data would start automatically, and the *Stop* button would throw an error. The issue was addressed by updating the condition that defines the `timerRunning`
variable, which controls whether the *Stop* button in the Timesheets app is displayed.

https://github.com/odoo/enterprise/blob/ac186aa71cd7e1b80b307ea12c7eaca246afd649/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L57-L64

Issue **I1** is a side effect of this change in the Project app, where the `timerRunning` variable is evaluated to `true`, causing the timer to be displayed when it should not.

The multiple timers running simultaneously (**I2**) stems from the `timerRunning` variable being initiated to false by default in the props.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L47-L50

The *Stop* button appearing after logging a task (**I3**) stems from the condition of the patch using `is_timer_running` over `timer_start`.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/hooks/sample_server_patch.js#L9-L15

## Fix
This commit reverts the problematic segments from the previous commit.

opw-5870756
opw-5879176
opw-5961764

Forward-Port-Of: odoo/enterprise#107014

Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
    a. Product A - storable - invoiced on Ordered Quantity
    b. Product B - service - create a task on order - invoice on 
    timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to 
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear

Problem
---------
During the creation of the invoice, the invoiceable lines would get 
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.

Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.

opw-6001094

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

Forward-Port-Of: odoo/odoo#261062