Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`

Traceback:
```py
 File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
    self._l10n_co_dian_send_event_update_status('received')
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
    document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
    xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
    return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
    'software_security_code': self._dian_get_security_code(operation_mode, document_number),
  File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
    operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```

We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.

[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432

[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400

sentry-7273771732

Forward-Port-Of: odoo/enterprise#107885

Problems:
-------
1. For a new employee, with a contract starting in the current month but before today:
in the payslip for the current month number of days of attendance and days of out of contract
are not correct

Same for an employee, with a contract ending in the current month (before today)

2. In both cases above worked entries are not generated correctly
(from today to the end of month)

3. Additional bug:
If we create an employee with no contract and create a payslip draft for him
for the current month, work entries with type "Attendance" will be created

Objective:
---------
Problems 1 and 2 :
date_version was equal to today (date of the employee's creation),
so number of attendance days was calculated as
( end_of_payslip_month - today ) or ( today - start_of_payslip_month )

Problem 3 :
Work entries are generated even when there is no active contract

Solution:
---------
Problems 1 and 2: This commit adds an additional part (already exists in v19) in the method
write() of hr.version which sets date_version = contract_date_start

Problem 3: by generating work entries check if contract_date_start is filled

Tests ware added in odoo/hr: test_hr_version.py
and in enterprise/hr_payroll:
test_new_employee_worked_days, test_payslip_empty_contract.py

task-5430759

Forward-Port-Of: odoo/odoo#251264
Forward-Port-Of: odoo/odoo#241978

### Steps to Reproduce:
1. Go to Accounting > Create a journal.
2. Archive the company’s default income/expense or cash diff. accounts.
3. Change the journal type.
3. Observe that an archived account is assigned by the onchange method.

### Issue:
- Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange]
(https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals.
- This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts.

### Solution:
- Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior.

OPW-5501539

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

Currently, editing a posted `miscellaneous` journal entry in Chile 
localization incorrectly raises a validation error.

**Steps to reproduce:**
- Install the `l10n_cl` module and switch to the `CL company`.
- Go to Accounting > Accounting > Journal Entries.
- Create a balanced entry using the `Miscellaneous journal `and `post` it.
- Reset it to draft, modify the `name`, and try to `save` it.

**Observation:**
`Validation error`: `The DTE document number (folio) must contain only digits.`

**Root cause:**
At [1], the constraint validation is applied to all journal entries in 
Chilean companies, including `miscellaneous` journals. However, 
`miscellaneous journals (move_type = 'entry')` are not linked to Chilean 
electronic documents, so the numeric folio validation should not apply to them.

**Fix:**
This commit ensures that the validation is not raised for `miscellaneous` journal 
types by excluding miscellaneous journals from the numeric folio validation constraint.

[1]:
https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30

opw-5926773

Forward-Port-Of: odoo/odoo#248965

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992

Forward-Port-Of: odoo/odoo#251270
Forward-Port-Of: odoo/odoo#243347

This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug.

Reproduce:
With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field.

After the fix:
The "Custom Url" field must not be displayed when URL does not contain a customisable slug.

Task-5114394

Forward-Port-Of: odoo/odoo#251294
Forward-Port-Of: odoo/odoo#231609

Version : saas-18.4+e

Steps to reproduce
------------------
Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”.

Create a purchase order for this product with the right vendor and confirm it.

Go to the delivery receipt, the vendor code and/or name are added twice in the description.

Why is it happening
------------------
The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name.

Solution
------------------
I propose to remove the code and the name from the vendor_reference variable if the original description already contains them.

opw-5392855

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

Forward-Port-Of: odoo/odoo#251337
Forward-Port-Of: odoo/odoo#242075

Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell (excluded), which may contain a cog menu. However, they only spanned to the second to last cell. As a consequence, in a list with only 2 columns, e.g. a handle and a name, the groups' name only got a few px available, and were hence cropped.

The issue came from successive reworks of the group header row, leading to the pager being finally moved from its own column (after the last aggregate column), to the group name cell (with ms-auto).

The logic is easier now, as a group header row looks like this:
- a single `<th colspan="n">` (n >= 1) to display the group name: spans to the first aggregate column excluded or to the last cell excluded if no aggregate (colspan + 1 if rows have selectors)
- one `<th colspan="1">` for each aggregate column
- optionally one `<th colspan="m">` (m >= 1) for all columns after the last aggregate column
- a single `<th colspan="1">` for the potential cog menu (optional dropdown column)

opw~5730396

Before
<img width="1918" height="471" alt="image" src="https://github.com/user-attachments/assets/8f55322b-1603-42cc-a48b-a2010ff12e25" />

After
<img width="1909" height="423" alt="image" src="https://github.com/user-attachments/assets/0bca4865-88a1-424d-a1af-1523dbfa911c" />

Forward-Port-Of: odoo/odoo#251411

Steps to Reproduce  
------------------  
1. Open the Planning Gantt view.
2. Click a cell that belongs to a resource with **no** scheduled shifts.  
3. The Plan dialog opens with an empty list.  
  
Issue  
-----  
A previous change  keeps the clicked resource in the dialog context; the Gantt 
model turns it into a default search filter, so only shifts already linked to 
that resource are shown. Unassigned shifts are therefore hidden, preventing 
planners from assigning them by role or availability.  
  
Current Behaviour  
-----------------  
The Plan dialog is always filtered by `resource_id`, which returns no results 
for unscheduled resources, even when they have the right roles.
  
Expected Behaviour  
------------------  
The dialog should list all unscheduled shifts that match the resource’s roles, 
or every unscheduled shift if the resource has no roles, while still preserving
full context for scheduling once a shift is selected.  
  
Fix  
---  
Remove the automatic resource filter from the dialog context in 
`getSelectCreateDialogProps()`. This prevents the unwanted search restriction; 
role defaults remain, so the dialog now displays the correct shifts.  
  
Task-4922525  
Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d

Forward-Port-Of: odoo/enterprise#92100