**Description of the issue/feature this PR addresses:**

When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database. 

**Current behavior before PR:**

You'll get this error:

```
odoo.service.db.restore_db(dbname, backup, copy, **extra_kwargs)
File "<decorator-gen-27>", line 2, in restore_db
File "/opt/ou/odoo/odoo/service/db.py", line 44, in if_db_mgt_enabled
return method(self, *args, **kwargs)
File "/opt/ou/odoo/odoo/service/db.py", line 360, in restore_db
env['ir.config_parameter'].init(force=True)
File "/opt/ou/odoo/addons/auth_oauth/models/ir_config_parameter.py", line 13, in init
oauth_oe = self.env.ref('auth_oauth.provider_openerp')
File "/opt/ou/odoo/odoo/api.py", line 611, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2059, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/opt/ou/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2052, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: auth_oauth.provider_openerp
Error: External ID not found in the system: auth_oauth.provider_openerp

```

**Desired behavior after PR is merged:**

No error will occur

The afflicted versions are AFAIK, **16.0**, **17.0**, **18.0**, and **19.0**


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

Forward-Port-Of: odoo/odoo#233633

**Problem:**
unbuilding a Manufactring order created through a subcontracting
process gives the wrong account move lines

**Steps to reproduce:**
- create a storable product (the comp) and set a cost
- create a storable product (the final product), set a cost
and set a vendor
- for the final product set the category as avco and automated
- for the final product create a bill of materials subcontracted
 and set the same vendor
- for the components add the comp for a quantity of 1
- create a Purchase order for the final product and the same vendor
and confirm
- validate the receipt
- From the receipt click on the valuation smart button and click on 
the book widget of the line of the final product
- notice how there is 3 journal items line including one 
crediting "stock interim (Received)"
- unarchive the operation type "subcontracting"
- open Manufacturing/Manufacturing Orders, delete the "to do" 
filter and search for a Manufacturing order with your final product
- unbuild it
- Open accounting/journal entries and select the journal entry for 
the unbuild

**Current behavior:**
There is only two account lines. 
There is no line balancing the "Stock Interim" line of the
manufacturing order.

**Cause of the issue:**
The override of _generate_valuation_lines_data in
mrp_subcontracted_account adds the stock interim line on the 
manufacturing order.
However when unbuilding, the qty is negative so we exit the function
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20

**fix**
Because subcontracted Manufacturing orders are not meant 
to be unbuilt, we prevent it

opw-4998137

Forward-Port-Of: odoo/odoo#230062

This error occurs when a user provides an invalid URL (e.g., one containing characters like “:”, “..”, etc.) in the link field.

Steps to reproduce:
---
- Install `appointment` module
- Appointment > Shared Links > New
- Fill `Appointment Types` > Link: `testurl:` (provide wrong link in Extra link)

Traceback:
---
`ValueError: Extra URL must use same scheme and host as base, and begin with base path`

At [1], this error occurs because during computation, the method calls `urljoin`. If the URL contains a colon (e.g., ‘:’), it is compared with the base URL, and when they differ, a `ValueError` is intentionally raised at [2]. This leads to the observed error.

This commit resolves the issue by catching the error when an invalid URL is provided.

[1]: https://github.com/odoo/enterprise/blob/fc931c81ca7b2ebad220cf057e15583e046810b9/appointment/models/appointment_invite.py#L280

[2]: https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/odoo/tools/urls.py#L55-L58

sentry-6941171133

- In Odoo 19, the pos.config fields sequence_id and sequence_line_id were
  renamed to order_seq_id and order_line_seq_id. The removed migration script
https://github.com/odoo/odoo/commit/2ead34e974f55dadf791ff6b2924edbf43442b34#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44R98-L132
  still referenced the old field names, causing UndefinedColumn errors during
  upgrade. The logic is already handled by the main migration script using the
https://github.com/odoo/upgrade/pull/8197/files#diff-d415d26b86040ad22ab82c184e6db20ec4e9a61058d9a9dbf3668ca21bcbaf19R42-R50
  new field names, so this file is no longer required.


```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1509, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 185, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 449, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 217, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/19.0/addons/l10n_fr_pos_cert/upgrades/1.1/post-sequence-no-gap.py", line 2, in migrate
    cr.execute("""
  File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
psycopg2.errors.UndefinedColumn: column pconfig.sequence_id does not exist
LINE 9:         AND (pconfig.sequence_id = iseq.id or pconfig.sequen...
                     ^
```

opw-5152559
upg-3179288
tbg-2205


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

Before this commit, the search panel in mailboxes (inbox, starred, history) took only part of the screen in mobile.

This happens because the template being used in mobile for mailbox is the same as desktop UI for discuss app. This component `DiscussContent` is used because mailboxes are not supported in chat windows, and full-screen conversations in discuss on mobile are actually chat windows. Reusing the `DiscussContent` component is almost the desired UX/UI. The side panel however was not designed for small screen, thus action panel is very narrow and is hard to use in mobile.

This commit fixes the issue by making the action panel mutually exclusive to message list in mobile, so that when search panel is open it takes the whole width of screen. We don't need to see message list in mobile, and thanks to chat window also using search panel that takes the whole screen, the search panel is already designed to auto-close itself and jump to a message.

Part of Task-4967066


Before / After

<img width="383" height="672" alt="Screenshot 2025-10-28 at 18 16 10" src="https://github.com/user-attachments/assets/f7a0bd0d-33ff-4e65-8b0e-0d3a0611b82c" />
<img width="382" height="673" alt="Screenshot 2025-10-28 at 18 15 52" src="https://github.com/user-attachments/assets/79f85cf1-e758-43fd-bc02-8e809e9795e3" />

Currently, an error occurs when a user attempts to access the stock valuation report for a date beyond today.

**Steps to replicate:**
- Install `stock_account`, `purchase_stock`, `accountant`.
- Go to settings, set `Inventory Cost Method` to Average Cost(AVCO) and Turn on `Lots and Serial Numbers`.
- Go to Products and create a new one with name `test`, set `Track Inventory` - `by lots`.
- On the `Inventory` page turn on `Valuation by Lots/Serial`.
- Open RFQs, Create a new one with test product and Click `Confirm Order` > Click `Receive`.
- Set the Lot name by clicking the `Details` button on the move lines.
- Click `Validate`, go to `Purchase > Orders > Purchase Orders`.
- Select the currently made Purchase Order (It will be in the `Waiting Bills` state) and Click on the `Create bills` Button, Confirm it (it should be in the paid state now).
- Now go to `Accountant > Review > Inventory Evaluation` and select and date ahead of today, the error will occur.

**TL;DR:**
- Install `stock_account, purchase_stock, and accountant`.
- Create a product tracked by lots with AVCO costing and `Valuation by Lots/Serial` enabled.
- Create a Purchase order and receive it (assign a lot), then create and confirm the bill for the same.
- Finally, go to `Accountant > Review > Inventory Valuation`, select a future date — the error occurs.

**Error:**
`TypeError: can't compare datetime.datetime to datetime.date`

**Cause:**
- The error occurs because of recent commit [PR] where `aml.date` is typecasted from `datetime.date` to `datetime.datetime`, but the `at_date` is received as `datetime.date` [1] and this causes the error.
- The `at_date` is converted to `datetime.date` from string at line [2].

**Solution:**
- Now we don't convert `aml.date` to datetime since both `aml.date` [3] and `at_date` [4] are instances of `datetime.date`. Additionally, `account.move` are based on date rather than datetime.

[PR]: https://github.com/odoo/odoo/pull/227567/commits/aec7d3244aa25af626cefd875f021d0d24ce418d

[1]: https://github.com/odoo/odoo/blob/7e0cc5ec686a52b8c1f8270213acac54575ed469/addons/purchase_stock/models/stock_move.py#L157

[2]: https://github.com/odoo/odoo/blob/7e0cc5ec686a52b8c1f8270213acac54575ed469/addons/stock_account/report/stock_valuation_report.py#L32

[3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/account/models/account_move_line.py#L69-L73

[4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_account/report/stock_valuation_report.py#L32

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

#### [FIX] account_peppol: disallow disabling services
Currently it is possible to disallow any services in the configuration.
This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0".

1. Ensure Peppol is activated (test mode or production; not demo)
2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services
3. Any service can be disabled.

This commit hides the button to open the service wizard.
(Also in the wizard it is now not possible to disable services anymore.)

#### [FIX] account: generation of print-related entries in cog menu
Before this commit:
The dynamic generation of the print related entries in the cog menu
does not work correctly.

Problem / Solutions:
There is a check in the javascript that does not work as intended.
Thus the entries are not added to the cog menu in all cases.
The check was intended to only block it for "new" records (not saved yet);
to avoid issues in case the move has no id yet.
After this commit we just check the id directly.

#### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format
Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce .
There we improved the eInvoice format labels for clarity.
But 2 label were formatted differently than the others.
This commit fixes that.

#### References
task-4737164

Forward-Port-Of: odoo/odoo#233629
Forward-Port-Of: odoo/odoo#233382

**Problem:**
landed cost does not work with MO

**Steps to reproduce:**
- in settings, enable the landed cost setting
- create two storable product (the final prod and the comp)
- set a positive cost on both
- set an on hand quantity for the comp
- set the category of the final product as avco perpetual
- create a BOM for the final prod where the component is 
the comp product.
- create a third product (the landed cost)
- for the product type select service 
- in the purchase tab check 'is landed cost'
- create a manufacturing order for the final product
- confirm and produce all
- navigate to Inventory/reporting/stock, search for your product
and notice the unit cost.
- open landed costs and click on New
- select the manufacturing order and add the landed cost
- validate 
- navigate to Inventory/reporting/stock 

**Current behavior:**
the unit price of your product has not changed.
I you navigate to Inventory/reporting/move analysis and check the move
with the reference of the MO, the value of the move has not changed 
either.

**Expected behavior:**
Both these value should have been impacted by the landed cost
like they would have if we were adding the landed
cost to a picking.

**Cause of the issue:**
When calling _get_value_data on a move, 
- If there is no production_id, the return value is computed 
in the super method.
There, when _get_value_from_account_move is called, 
https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_account/models/stock_move.py#L299
the override in sotck_landed_costs adds the landed costs to 'value'
https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_landed_costs/models/stock_move.py#L18-L22
- But if the move has 
a production_id the return is computed in the mrp_account 
override.
https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/mrp_account/models/stock_move.py#L14-L19
But there is no mechanism to take into account the landed cost.


opw-5170554

Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.

Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.

This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.

This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.

Forward-Port-Of: odoo/enterprise#93205

**Traceback :**
```
File "/home/odoo/src/odoo/19.0/addons/hr_recruitment_skills/models/
hr_applicant.py", line 72, in _compute_matching_skill_ids
  matching_score = round(applicant_total / job_total * 100)
ZeroDivisionError: float division by zero
```

**Steps to Reproduce:**
- Install recruitment app.
- For any job position, select all expected skill level such that level_progress
  is 0 and no expected degree .

**Description:**
- While calculating matching score for applicants here 
https://github.com/odoo/odoo/blob/19.0/addons/hr_recruitment_skills/models/hr_applicant.py#L72
a ZeroDivisionError occurs if 'job_total' is zero.

- This situation occured because in 19 version new feature to calculate applicants 
matching score was introduced in https://github.com/odoo/odoo/commit/164b55c324e63c45339088823e3d55dfe2147b61
and job_degree,applicant_degree, level_progress in skills for job and applicants 
were not present in older versions making job_total as 0 causing above traceback

- This commit adds a safety check to ensure the division only occurs
if 'job_total' is non-zero . and if job_total is 0 , there is no expectation 
required for this position which makes matching score 100 .