When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119760
Forward-Port-Of: odoo/enterprise#118759

#### Description of the issue/feature this PR addresses:
In the Singapore localization (l10n_sg), reverse charge is modelled as a group tax pairing a -9% SRRC child with a +9% TXRC child, so the GST on a bill nets to zero while both legs are still reported in their respective GST return boxes. The child taxes "9% TXRC-TS" and "9% TXRC-ESS" shipped inactive, while their siblings "9% TXRC-N33" and "9% TXRC-RE" shipped active. Because children_tax_ids is a many2many onto account.tax (which has an active field), inactive children are filtered out of the group, so the groups "Reverse Charge - SRRC + TXRC-TS" and "Reverse Charge - SRRC + TXRC-ESS" only kept the -9% SRRC leg and computed a wrong GST amount, while leaving the +9% leg out of the GST return.

#### Current behavior before PR:
A vendor bill of S$10,000 taxed with "Reverse Charge - SRRC + TXRC-ESS" (or "+ TXRC-TS") shows 9% GST = -S$900.00 and a total of S$9,100.00 instead of net S$0.00 / S$10,000.00. The +9% TXRC leg never reaches Box 5 / Box 7 of the GST return. The sibling groups "+ TXRC-N33" and "+ TXRC-RE" are unaffected because their children are active. The only workaround is to manually activate the two child taxes.

#### Desired behavior after PR is merged:
The "9% TXRC-TS" and "9% TXRC-ESS" child taxes are active by default, so the group taxes aggregate both legs: a S$10,000 bill shows 9% GST = S$0.00 with a total of S$10,000.00, and both reverse charge legs land in their GST return boxes. New SG databases get this from the tax template; existing SG databases get the two taxes reactivated by a migration on upgrade.

opw-6199248

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

Forward-Port-Of: odoo/odoo#267670

Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Forward-Port-Of: odoo/enterprise#119761
Forward-Port-Of: odoo/enterprise#113618

### Issue before this commit:
In accrual reports (e.g., "Bill To Receive", "Billed Not Received", "Invoices To Be Issued", and "Invoices Not Delivered"), when grouping the list view by fields such as Vendor, the group header totals for the "Received", "Billed", and "Amount" columns display 0.00 even if the interanl lines of the group are not 0.00.

### Steps to reproduce the issue:
1. Download Purchase Accounting and Sale Accounting
2. Go to one of this pages: Billed Not Received, Bill To Receive, Invoices To Be Issued, and Invoices Not Delivered
3. Ensure the view is in its default grouping (grouped by Vendor or Customer)
4. Observe the group header rows for the Received (or Delivered), Billed (or Invoiced), and Amount columns. They all display 0.00
5. Expand a group that contains records with values greater than zero
6. Observe that the individual records populate correctly, but the aggregated group header row continues to display 0.00.

### Cause of the issue:
The commit ddc1b681656ea8c70f3231cda20b5a58b9ff7dd6 adapted the code to retrieve the new accrual reports but attempted to fetch grouped records using group[0].id as the dictionary key, while the grouped() method actually used the recordset object as the key. This mismatch caused the dictionary lookup to fail, resulting in 0.00 sums. https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/account_accountant/models/analytic_mixin.py#L40-L48

### Reason to introduce the fix:
This fix restores the core analytical utility of the accrual reports, which are crucial for accountants during period-end closings to evaluate totals at a glance.

opw-6232273

Forward-Port-Of: odoo/enterprise#118399

### Steps to reproduce:

- Enable `Lots & Serial Numbers` and `Packages` in the settings
- Create a product tracked by SN and add SN001 and SN002 to stock
- Create and confirm a delivery for 2 units
- Open the Barcode app and open the delivery
- Scan the product > Scan SN001
- Click `Put in Pack`

### Current behavior:

The created package is not displayed anywhere. Clicking Put in Pack again nests the package into another package without any visible indication to the user.

### Cause of the Issue:

The GroupedLineComponent cannot display neither the source or destination package:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.xml#L4-L21
However, our case the grouped line contains only a single line and prevents the users from viewing the sublines since the `Show Reserved Lots` is disabled on the operation type and only one lot (with additional demand) was scanned:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L75-L77 https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L44-L55

opw-6237834

Forward-Port-Of: odoo/enterprise#119114

Cause:
----------------------------------------
Commit 121806b57816d0fbd48b5538d2a8beae35905d99 added a test verifying that the duration in German is correctly recognized. In the test, "2 Std. 30 Min. 45 Sek.", was supposed to be recognized as 2.5125 hours. But on some browser versions it fails, as in the latest Chrome version.

This is because we use `DurationFormat()` to get the localized units. This method is supported by all browsers and will use the browser's data to get the translations. This data comes from [Unicode CLDR](https://cldr.unicode.org/) which is updated regularly.

We would need to change the test depending on the Chrome version, so we just delete it. It appears that for German hours the CLDR definitions have historically shifted between two distinct representations: "Std." and "h"

As an example:
- CLDR 47:
https://github.com/unicode-org/cldr-json/blob/16f6b8578ba5fe98959034706f337674f816fc3f/cldr-json/cldr-units-full/main/de/units.json#L3526-L3527

- CLDR 48:
https://github.com/unicode-org/cldr-json/blame/4d06be52b51bb2f75688d0abe55c52a66afed790/cldr-json/cldr-units-full/main/de/units.json#L3916-L3917


So the test fails in CLDR 48 but succeeds in CLDR 47.

As the latest version of `ICU` (used by browsers) updates its dependency to CLDR 48 ([src](https://unicode-org.github.io/icu/download/78.html)) this explains why the latest Chrome version makes the test fail.

runbot-939543

Forward-Port-Of: odoo/odoo#268891

## Steps to reproduce:
	- Install l10n_be_hr_payroll module
	- Create a flexible working schedule and set the company to the Belgian company
	- Create an employee and assign the created schedule to him
	- Try to take a multi-day leave for this employee
	- Notice number of days is 0
	- Try to validate the leave
	- An exception is raised 'The following employees are not supposed to work during that period'

## Cause:
When fetching the work intervals for a belgian flexible employee we first fetch the normal work intervals then we call the same method but to filter the time credit attendance and since for the flexible employee there are not specific attendances we return the same normal work intervals and it will subtract those from the main work intervals which will result in an empty intervals to be returned

## Fix:
Check if the working schedule is flexible and if so we don't check the time credit attendances at all.

opw-6237642

Forward-Port-Of: odoo/enterprise#118701
Forward-Port-Of: odoo/enterprise#118528

### Issue
When setting the partial deductibility percentage to 99% on a vendor bill line, the system incorrectly treats it as 100% deductible and completely ignores the non-deductible part

Additionally, changing the deductibility percentage on a line with taxes does not trigger an update of the
non-deductible tax journal items, leaving the private part taxes unchanged

### Cause
In the tax recomputation mechanism, `float_compare` was wrongly configured with `precision_rounding=2` instead of `precision_digits=2` when checking the `deductible_amount` field

This rounding error caused 99.00 to be evaluated as equal to 100.00, skipping the creation of the non-deductible line

Furthermore, `_sync_tax_lines` relies on `get_base_line_tracked_fields` to detect modifications that require a tax recalculation

This tracked field list only included price, quantity, and discount. Modifying the deductibility percentage did not trigger any sync, preventing the non-deductible tax lines from adjusting

### Fix
To fix the synchronization, `deductible_amount` is added to the tracked fields for invoices
This straightforward approach is preferred here for simplicity
However, a more restrictive condition may be needed for example only check it on lines with taxes

### Steps to reproduce
- Install `account`
- Create a Vendor Bill  (Price: 1000$, Taxes: 15%, Professional %: 50)
- Check the Journal Items tab to see the Private Part line at 500$ debit and Private Part (taxes) line at 75$ debit
- Change the Professional % field on the invoice line to 75 Before the fix, the Private Part (taxes) line remains at 75$ debit
- Change the Professional % field on the invoice line to 99 Before the fix, the private part lines completely disappear instead of adapting to 1%

opw-6245909

Forward-Port-Of: odoo/odoo#267427

Steps to produce:
---
- Install `website_sale` module.
- Create a product with a variant and add the images from the sale tab.
- Go to the product on the e-commerce and change the variant.
- Attempt to scroll through the product images (using the mouse wheel).

Issue:
---
- After changing a product variant on the eCommerce product page, attempting to scroll through the product images (using mouse wheel) has no effect.

Root cause:
---
- When a product variant is changed, `_updateProductImage` dynamically replaces the product image carousel DOM element (`#o-carousel-product`) by injecting new HTML and removing the old one.
- The old CarouselProduct interaction instance remains in memory, causing a resource and event listener leak on the detached old DOM element.
- The newly inserted `#o-carousel-product` element is ignored by the interaction service, meaning that the CarouselProduct interaction is never initialized on the new carousel. This leaves the new carousel static and unresponsive to user interactions.

Solution:
---
- Before replacing the carousel DOM node, manually notify the public.interactions service to clean up any active interactions on the old element. After the new DOM node is queried, start the interactions on the new element.

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

Forward-Port-Of: odoo/odoo#269170
Forward-Port-Of: odoo/odoo#265537

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#119941
Forward-Port-Of: odoo/enterprise#102864

In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors.

This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow:
1. Add the unmodified source page directly to the `PdfFileWriter`.
2. Retrieve the newly created, writable output page.
3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page.

[^1]: https://github.com/py-pdf/pypdf/pull/3638
[^2]: https://github.com/py-pdf/pypdf/pull/3669

Forward-Port-Of: odoo/odoo#268865
Forward-Port-Of: odoo/odoo#267958

In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors.

This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow:
1. Add the unmodified source page directly to the `PdfFileWriter`.
2. Retrieve the newly created, writable output page.
3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page.

[^1]: https://github.com/py-pdf/pypdf/pull/3638
[^2]: https://github.com/py-pdf/pypdf/pull/3669

Forward-Port-Of: odoo/enterprise#119694
Forward-Port-Of: odoo/enterprise#119239

When a calendar event has multiple attendees, `_get_contact_details_description` picks the first non-organizer partner from a set-based recordset to render under "Contact Details" in the event description. The recordset is built from `partner_ids_from_attendees`, a set whose iteration order depends on Python's hash seed, so the displayed contact is effectively random and not controllable from the UI.

Restrict the "Contact Details" block in `_get_contact_details_description` to events with exactly one non-organizer attendee (1-on-1 meetings). For group meetings the block is omitted entirely, since any single attendee picked from a larger group is arbitrary by construction.

Steps to reproduce:
1. Go to Calendar > New
2. Add 3+ attendees (e.g. Alice, Bob, Charlie)
3. Save the event
4. Check the Notes tab in the event form

=> One random attendee's contact info appears under "Contact Details"

Ticket [link](https://www.odoo.com/odoo/project.task/6035192)
opw-6035192

Forward-Port-Of: odoo/odoo#258901

Steps to produce:
---
- Install `website_sale` module.
- Enable ` Units of Measure & Packagings `and `Comparison Price` features from settings.
- Create product > set sales price as 5 and Compare to Price as 12.
- From the sales tab, under Upsell & Cross-Sell > set Packagings as pack of 6.
- Go to the shop page on eCommerce, and add your product via the shop page (this should open the product configurator).
- Change the UOM from the radio.

Issue:
---
- Changing the UOM doesn't change the strikethrough price.

Root cause:
---
- At [1], The `_get_strikethrough_price` method was not receiving the selected uom parameter, causing it to compute the compare_list_price based on the product's base uom instead of the user-selected uom.

Solution:
---
- Pass `uom` parameter from `_get_basic_product_information` to `_get_strikethrough_price`
- Apply uom conversion to compare_list_price when the selected uom differs from the product's base uom.
- Also fix pricelist base price calculation to use the selected uom.
- Update the JS logic to refresh the strikethrough price when the uom
  changes.

[1]https://github.com/odoo/odoo/blob/bfcb22256226ae056e934e2f9e498e8cea4d2f63/addons/website_sale/controllers/product_configurator.py#L101-L154

Before:
---
<img width="974" height="321" alt="image" src="https://github.com/user-attachments/assets/f360d730-bedf-4898-ba22-c47ea8fa1df7" />

After:
---
<img width="977" height="321" alt="image" src="https://github.com/user-attachments/assets/79d66143-959c-4f39-9272-437cb768837e" />


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

Forward-Port-Of: odoo/odoo#263556

Issue:
When the sales price is changed from the product variant form for a product without configured variants, the price is updated only on `product.product.lst_price`. The main product form, opened from Inventory > Products, displays `product.template.list_price`, which remains unchanged. The same issue is visible from Purchase Orders because the product internal link on a purchase order line opens `product.product`, while the product page opens `product.template`.

Steps to reproduce:
- Create or open a product without configured variants
- Open product variant form from the internal link in a purchase order
- Change the Sales Price on the product from there
- Open the product from Inventory > Products (`product.template`)
- The template Sales Price still shows the old value

Cause:
Since version 19.1, `product.product.lst_price` is an editable stored field, allowing variant-level prices to differ from the template price. This is correct for products with multiple variants, where each variant may have its own sales price. However, for products with only one variant (the product itself), no synchronization was performed from `product.product.lst_price` back to `product.template.list_price`, leaving both product forms inconsistent.

Solution:
- Add `_inverse_product_lst_price` on `product.product.lst_price` so that When `lst_price` is written and the template has exactly one variant, set `list_price` to `lst_price` (delegates to the template)

opw-6260015

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

Forward-Port-Of: odoo/odoo#268017

### *Why this commit*: 
---
Ensures Quality Checks and Mass Produce options remain available on the
Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid both the Quality Checks and Mass Produce buttons.
This blocked users from registering Serial Numbers and completing mandatory
quality check steps.

Additionally, for products without BoM operations, clicking Mass Produce 
triggered quality check validation instead leading to errors, preventing the
generation of serial numbers.


### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Mass Produce: Stays visible to allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.


OPW: 5473839

Forward-Port-Of: odoo/enterprise#117829
Forward-Port-Of: odoo/enterprise#103926

Steps to reproduce:
1. Install website_sale_renting_planning
2. In rental module,  create a product that is of type service and can be sold
3. Go to the website and remove the quantity selector input field from the page and save.

Issue:
`TypeError: Cannot read properties of null (reading 'dataset')`

Why this happens:
Following architectural changes in v19.1, the rental data evaluation logic was moved directly into the DaterangePicker component lifecycle. Commit 4e5f71d introduces a new method to where, during initialization (`willStart`), the component triggers `setAddQtyInputMax()` to update the dataset attributes of the quantity selector input box. If the quantity selector has been removed via the website customizer `querySelector` returns `null`, causing the assignment to crash.
In v19.0, this logic lived in the `WebsiteSale` interaction, executing only during post-render UI event listener triggers which kept it safe.

opw-6268945

Forward-Port-Of: odoo/enterprise#119574

Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
    * Trigger: On Creation
    * Action To Do: Execute AI Action
    * Add a server action tool with 'Create Next Activity' action
    * Set Activity User Type to Dynamic
    * Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user

Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths

Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed

Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module

opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530

Forward-Port-Of: odoo/enterprise#119179
Forward-Port-Of: odoo/enterprise#118921

[FIX] account_reports: only restore horizontal group from previous_options when it's available

The 'Ledger' group will only be available when in multicompany or using different journal groups. It was still restored from previous options, even when it shouldn't have been available.


=============================================


[FIX] account_reports: properly compute Ledger group when there's no journal group

To reproduce the issue

1) Populate the db with some data impacting the Balance Sheet
2) Delete all the journal groups that would be created by default
3) Open the Balance Sheet, with multiple companies active.
4) Select the "Ledger" horizontal group
====> The report is displayed horizontally grouped by company, but all amounts are 0.

This happens because, when no journal group exists, the "Ledger" horizontal group creates a column group per company, applying a domain doing ('journal_id', 'in', []), so nothing matches. This is caused by the fact that, in this case, options['journals'] will require to match all journals, and will hence be an empty list. We fix it by properly searching for all journals to build the horizontal group's domain when options['journals'] is empty.

A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity).

The issue this causes is that it can open the expiration popup since from saas-18.4 there is a line where if `ml.removal_date <= datetime.datetime.now()` the picking is expired.

So, if the product previously met these conditions, it will still be able to enter this flow.

And since this product doesn't use a lot_id it displays “You are going to deliver the product False, False which is expired or should at least be removed from stock”

What should happen:
When a product is not tracked, use_expiration_date should be False as expiration dates are intended to be managed through lots or serial numbers.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
- Tracking: By Lots
- Use Expiration Date: enabled
- Set a value greater than 0 for removal_time
3. Change the product tracking to By Quantity.
4. Create and validate a receipt for the product.

Related Tickets: opw-6255673

Forward-Port-Of: odoo/odoo#268965
Forward-Port-Of: odoo/odoo#268135

**Steps to reproduce:**

- Install pos_mrp
- Make a BoM for a product
- The product must have a custom attribute, of type always
- Go to the PoS
- Make a sale, with a customer, enable Ship Later
- Go to the created MO
- The Custom Description field is not showing

**Why the fix:**

This fix was previously done by e53dae2 but it did not account for the other variants and only did the fix for the never attributes.
This is because it seemed to work with other kinds of attributes until 19.0

We now also compute the move description if we have a custom attribute. We need the never variants to have a description as well, as it is done in the sale module. This commit basically aligns the behavior to the on done in the sale module.

A test had to be changed, as we now write the description in a different way, to make it the same regardless of where the picking and moves were created from. We now won't see a difference on the MO between one created from the POS and one created through the sale module.

opw-6169257

Forward-Port-Of: odoo/odoo#268713
Forward-Port-Of: odoo/odoo#263350

The display name of the account.report.line in the general ledger report has the format of:

INVOICE NAME (invoice refs)

In the case where a client has hundreds of sales orders batched to a single invoice, the ref can
become extremely long, e.g.:

INV/2026/00001 (S12123, S12152, S12159, S12140, S12165, S12161, S12162, S12110, S12099, S12124, S12145, S12128, S12114, S12131, S12097, S12185, S12154, S12133, S12190, S12118, S12116, S12102, S12155, S12153, S12158, S12150, S12100, S12142, S12121, S12122, S12111, S12187, S12172, S12177, S12095, S12117, S12144, S12137, S12092, S12138, S12186, S12182, S12112, S12148, S12183, S12101, S12178, S12119, S12169, S12115, S12146, S12093, S12126, S12160, S12163, S12129, S12098, S12151, S12096, S12174, S12120, S12130, S12147, S12180, S12191, S12164, S12141, S12105, S12136, S12139, S12109, S12106, S12104, S12103, S12175, S12179, S12188, S12113, S12173, S12167, S12171, S12134, S12094, S12184, S12166, S12170, S12125, S12135, S12143, S12176, S12189, S12156, S12181, S12107, S12157, S12132, S12149, S12127, S12108, S12168...)

Because the length of the account.report.line is unchecked in account_general_ledger.py label
builder, the pdf can clog to one or two account.report.lines per page, skyrocketing the pdf page length.

As wkhtmltopdf processes the report from html to pdf it makes a system call openat() to the /tmp/report.footer.tmp.x.html file for EACH page of the pdf. You can see the TODO comment in the spoolTo function in wkhtmltopdf (both in Odoo and the original repo) saying that the header and footer need to be freed, on each page processing, not just null pointed.

https://github.com/odoo/wkhtmltopdf/blob/2c884bd1545b8a639847de22f24754ee5a6fc44c/src/lib/pdfconverter.cc#L794

I verified that that the number of openat calls to the /tmp/report.footer.tmp.x.html file equals the exact number of pages in the pdf to be generated if the report HAD generated successfully by setting the footer input into
_run_wkhtmltopdf to None, generating the report without footers, then separately running an strace on wkhtmltopdf when the report fails to generate. See related ticket linked at bottom.

The linux machine used on sh instances has a ulimit -n of 1024 file descriptors. Because
the footer file descriptors accumulate, once a pdf has about 1010+ pages (~a dozen fd's are allocated for other purposes), over 1024 file descriptors are opened and the system fails with:

Wkhtmltopdf failed (error code: -6). Message:
QEventDispatcherUNIXPrivate(): Unable to create
thread pipe: Too many open files
QEventDispatcherUNIXPrivate(): Can not continue
without a thread pipe

Since wkhtmltopdf is archived and Odoo has a replacement in development, I suggest that we limit the display_name of the account.report.line to 200 to keep the bloat minimized, preventing one account.report.line's name from taking up an entire page of the general ledger pdf. This allows many more batched invoices to be shown in the report and a much greater time range of data to be printed without hitting the fd limit.

I suggest changing it at the general ledger report level rather than in the account.move.line
_compute_display_name function, as we probably still want to see the full display_names at the invoice level.

On runbot, the machine has different memory constraints than on sh / local, so it hits the following error before the one above:

Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum file number of subprocess
reached. Message :

Steps to Reproduce on 19.0 newdb:

1. newdb -n test_gl -v 19.0
2. ensure ulimit is set to 1024 in shell that runs odoo instance by running ulimit -n 1024 to
mimic ulimit of sh environment
3. run db with python3 odoo-bin, ensuring high enough memory constraints to simulate multi
worker sh instance, i.e.
--limit-memory-soft=12884901888
--limit-memory-hard=1288490188
4. install sales, accounting, stock
5. install demo data
6. create invoices with 100+ associated sales orders
7. generate the pdf
8. Increase the amount of invoices till the general ledger page count hits ~1010+, where you will
hit the error.

Notes:
opw-ticket-6201508

closes #118067

Forward-Port-Of: odoo/enterprise#120091
Forward-Port-Of: odoo/enterprise#118067

## Issue
When using a prefix containing a time-based placeholder (`%(h24)s`, `%(h12)s`, `%(min)s`, `%(sec)s`) with *Subsequences per date\_range*, the time information are missing and consistently set to 0 when interpolating the prefix.

## Steps to reproduce
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, update the `sale.order` sequence:
    - Prefix: `S/%(y)s/%(month)s/`
    - Suffix: `/%(h24)s/%(min)s/%(sec)s`
    - Tick the *Use subsequences per date_range* checkbox and set a range for the current month
3. Create and confirm a SO
4. **The name of the SO correctly contains the Quotation date in the prefix, but the suffix is set to /00/00/00, even though the quotation date contains time information.**

## Cause
Commit https://github.com/odoo/odoo/commit/f7c330d83cc3 sets the `ir_sequence_date` to a `datetime.date` object in `IrSequence._next`. This leads to the time information missing from the interpolation dict:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/addons/base/models/ir_sequence.py#L211-L214

## Fix
The context key `ir_sequence_date` should be set to a `datetime.datetime` object to correctly interpolate the time information in the prefix/suffix of a sequence. To do so, the `tzinfo` needs to be drop for the date to be interpretable by the `fields.Datetime.from_string` method:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/orm/fields_temporal.py#L239-L244

The time is not cast to a specific timezone (e.g., UTC) before dropping the tzinfo, as doing so would lead to incoherent time information from the user's perspective. For example, creating a SO at 13:00 in Brussels (UTC+2) would result in  `11` being used as the hour to interpolate the `%(h24)s` placeholder.

opw-6104485

Forward-Port-Of: odoo/odoo#260782