Steps to reproduce the bug:
- Create a storable product “P1”
    - Under the Purchase tab:
        - add two vendor pricelist entries:
        1:/
        - Vendor: Azure Interior
        - min_qty: 1
        - Price: $5 
         2:/
          - Vendor: Azure Interior
          - min_qty: 100
          - Price: $2

- Create a purchase order:
    - vendor: Azure Interior
    - Try to add the product P1

**Problem:**
When adding a product to a purchase order, if multiple supplier info
lines exist for the same vendor,  the one with the lowest price will be
selected, instead of the one matching the smallest applicable quantity
(min_qty).

This regression was introduced by the following commit, which
tried to fix an unrelated bug with supplier info date matching:
https://github.com/odoo/odoo/commit/7eabfcff402993f32f5c835e18e07c91782a7b33#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224L470

As part of that fix, the logic was changed to use the _select_seller
method, which by default sorts supplier info lines by price_discounted
and returns the first one — regardless of whether the min_qty is met.

Previously, the logic correctly selected the supplier line based
on min_qty when multiple lines existed for the same vendor.

**_Note:_** This bug is no longer present as of version 18.1, because
the date-related issue was fixed differently in the following commit:
https://github.com/odoo/odoo/commit/19c65c4884a3746b44b6272694662eb32a6bf32f

That later fix preserved the original behavior of respecting min_qty.

**Solution:**
Explicitly pass ordered_by='min_qty' when calling _select_seller.
This ensures that supplier info lines are prioritized based on the
lowest applicable min_qty, not the lowest price, when the vendor is the
same.

opw-4942819

Forward-Port-Of: odoo/odoo#221902
Forward-Port-Of: odoo/odoo#221764

This commit fixes two issues related to project propagation from Sale Order to Purchase Order:

**1. Project not propagated when using MTO+Buy route**

**Steps to reproduce:**
- Install only `sale_project_stock` and `purchase`
- Enable multi-step routes and unarchive the "MTO" route
- Create a storable product "P1" with:
  - Routes: MTO + Buy
  - Vendor: any
- Create a Sale Order with:
  - 1 unit of P1
  - Any project set in "Other Info"
- Confirm the SO

**Issue:**
A Purchase Order is created but the project is not propagated to it. This propagation was previously ensured by `project_mrp_sale`, via:

https://github.com/odoo/odoo/blob/238a41e35280256382f6509182b9e900fb4f7aba/addons/project_mrp_sale/models/stock_move.py#L9

---

**2. Project not propagated when using drop-shipping**

**Steps to reproduce:**
- Enable drop-shipping
- Create a product "P2" with:
  - Route: Drop-Ship
- Create a Sale Order with:
  - 1 unit of P2
  - Any project set
- Confirm the SO

**Issue:**
A Purchase Order is created, but the project is again missing.

---

**Fix:**
- Move the `_prepare_procurement_values` override from `project_mrp_sale` to `sale_project_stock` to ensure project propagation regardless of the presence of `project_mrp_sale`
- Also adapt `sale_project` to ensure project is retrieved from the Sale Order if not set on the Sale Order Line.

opw-4976606

Forward-Port-Of: odoo/odoo#222179

With the French fiscal localization:
When an employee has a different working schedule than the company’s default one. If the employee’s daily working hours are greater than the company’s default hours. The timesheet for paid time off only displays the company’s default hours instead of the employee’s actual hours.

Steps to reproduce:
-------------------
* Install l10n_fr_hr_holidays
* Set the French fiscal localization
* Working schedule of the company -> 7:30 per day
* Working schedule of the employee -> 8 per day
* Create a paid time-off with this employee
* Check the Timesheet of this employee

> Observation:
Timesheet shows 7:30 instead of 8

Why the fix:
------------
We needed to ensure the hours are always calculated correctly (using the employee’s or company’s calendar when appropriate) while still forcing the correct day count (1 or 0.5) and extending it according to French law.

✅ Day count is forced (0.5 or 1) depending on the leave type.
✅ Hours are fetched from  `super()._get_durations()` so the timesheet keeps accurate hours.

This prevents timesheets from showing incorrect hours when the employee's work schedule differs from the company's work schedule.

opw-4744516

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

Forward-Port-Of: odoo/odoo#220511

# How to reproduce the issue

With l10n_es fiscal position:

- Create a bill in a previous period (e.g., amount 1000). Partially credit note this bill for 500.
- Register a partial payment of 250 on this bill.
- In the tax report, go to model 349.

Under the Rectificationes section, the new rectified value will be 250. This is incorrect, as the rectifications in this report should only reflect the value of the original move from a past period after applying the credit note. Payments or other transactions should not impact this report.

This commit adjusts the computation of the report (and the BOE export) to ensure that, instead of using `amount_residual` (which includes payments and other transactions), the report uses the sum of the credit notes linked to the move included in the rectification report.

Also changed the test test_mod349_credit_note. The rectification section is supposed to show the adjusted amount after rectification. In the test a bill of 400 is fully refunded. Instead of 400, the report should show 0.
(https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 in TIPO DE REGISTRO 2: REGISTRO DE RECTIFICACIONES. in 153-165 Numérico Base Imponible Rectificada section)

opw-4895636

Forward-Port-Of: odoo/enterprise#91350
Forward-Port-Of: odoo/enterprise#89431

Steps to reproduce:
- Do not enable “Rental Transfer” in settings
- Create a storable product “P1”:
    - Enable “Can be rented”
    - update available quantity to 10 units

- Create a first rental order for 24h:
    - 9 units of P1
    - Confirm the order

- Create a second rental order for the same 24h period:
   - 1 unit of P1

-> Expected: The availability widget is green and indicates 1 unit available (correct).

Problem:
After picking up the first order, the widget on the second order turns red and incorrectly shows no availability.
The current logic checks virtual_available (1 unit) and subtracts rented_qty_during_period (9 units), resulting in -8. It then takes max(0, -8) → 0. However, the actual picked quantity should be taken into account, regardless of whether “Rental Transfer” is enabled, since disabling it merely omits the creation of a picking—not the move itself.

opw-4901017
opw-4906162

Forward-Port-Of: odoo/enterprise#92056
Forward-Port-Of: odoo/enterprise#91155

Currently, an error occurs when the user tries to install multiple modules and, during
installation user tries to access any app.

This issue happens because line [1] tries to get view info by view name, like `hierarchy`.
Normally, we get the view information from the `_get_view_info`  method (see [2]), and we
override this method to add another view to the returned data (as in [3]).

But during installation, when the user tries to access any app, the view is already loaded into the
database. So when the `fields_get` method is called, the view is found. However, since the module
isn't fully loaded yet, the overridden `get_view_info` method hasn't taken effect. As a result, the
additional view we expect isn’t included, and accessing that view key causes an error.

This commit fixes the above error by ensuring that `_view_info` is accessed only when
`type_` is present in `_view_info` at [1].

[1]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web/models/ir_ui_view.py#L14
[2]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web/models/ir_ui_view.py#L22-L31
[3]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web_hierarchy/models/ir_ui_view.py#L56-L57

sentry-5661154820

Steps to reproduce the issue:
1. Create a new activity on any `mail.thread` (`project.project` for example)
2. On the wizard, upload an attachment
3. Schedule the activity
4. Upgrade the database to any future version

Current behavior before PR:
The attachments created with activities would be deleted due to the query [here](https://github.com/odoo/upgrade/blob/master/migrations/base/0.0.0/pre-clean-transients.py#L69),
because they are linked to the transient model `mail.activity.scheduel`. Attachments linked to these models are deleted during the upgrade.

Desired behavior after PR is merged:
The newly created attachments are linked to the `mail.activity` record directly, avoiding the post-upgrade issue. This change also aligns the feature with attaching a file to a `mail.message` record, where the `res_model` and `res_id` fields move from `mail.compose.message` to the target model after posting the message.

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

### Steps to reproduce:
	- Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours.
	- Create a public holiday with generic time off work entry type.
	- Create one or multiple attendances for marc demo on the public holiday.
	- Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h.

### Cause:
This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day

### Fix:
We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day

opw-4887933

When generating PDF reports with multiple records, the system tries to split the concatenated PDF using outlines. However, in cases where the number of outlines doesn't match the number of records or outlines are missing, it falls back to generating individual PDFs per record by recursively calling `_render_qweb_pdf_prepare_streams()` for each `res_id`.

This ensures that each record gets its corresponding PDF even if splitting the combined PDF is not possible due to template or wkhtmltopdf inconsistencies.

issue related: https://github.com/odoo/odoo/issues/202299

Current Behavior:
The _render_qweb_pdf_prepare_streams method does not correctly generate PDF streams under specific conditions, causing the PDF to not be properly split for each res_id. When these conditions are met, the generated streams are set to None, resulting in incorrect PDF processing.

The issue occurs when all the following conditions are true:

reader.numPages != len(res_ids_wo_stream)
len(res_ids_wo_stream) > 1 and set(res_ids_wo_stream) == set(html_ids_wo_none) is True
not has_valid_outlines is False
has_same_number_of_outlines and has_top_level_heading is False, since has_same_number_of_outlines is False
Expected Behavior:
The method should correctly assign a valid PDF stream to each res_id, ensuring proper document splitting even when outlines cannot be used.

Steps to Reproduce:

Generate a PDF report where the number of pages does not match the number of res_ids.
Ensure that the report includes multiple records, and the outlines structure is not valid for splitting.
Debug and Observe that the streams assigned to res_ids are None, leading to issues in PDF rendering.
Error:
Odoo Server Error

RPC_ERROR
Odoo Server Error

Occured on 172.20.18.5:8069 on model ir.cron and id 31 on 2025-03-18 12:02:43 GMT

Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/tools/safe_eval.py", line 397, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(309,)", line 1, in
File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 5481, in _cron_account_move_send
self.env['account.move.send']._generate_and_send_invoices(
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 687, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 612, in _generate_invoice_documents
self._prepare_invoice_pdf_report(batch)
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 333, in _prepare_invoice_pdf_report
content_by_id = self.env['ir.actions.report']._get_splitted_report(pdf_report.report_name, content, report_type)
File "/home/odoo/src/odoo/addons/account/models/ir_actions_report.py", line 60, in _get_splitted_report
pdf_dict = {res_id: stream['stream'].getvalue() for res_id, stream in content.items()}
File "/home/odoo/src/odoo/addons/account/models/ir_actions_report.py", line 60, in
pdf_dict = {res_id: stream['stream'].getvalue() for res_id, stream in content.items()}
AttributeError: 'NoneType' object has no attribute 'getvalue'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 1962, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 156, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1929, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/odoo/api.py", line 533, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_cron.py", line 120, in method_direct_trigger
self.ir_actions_server_id.run()
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_actions.py", line 995, in run
res = runner(run_self, eval_context=eval_context)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_actions.py", line 827, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "/home/odoo/src/odoo/odoo/tools/safe_eval.py", line 411, in safe_eval
raise ValueError('%r while evaluating\n%r' % (e, expr))
ValueError: AttributeError("'NoneType' object has no attribute 'getvalue'") while evaluating
'model._cron_account_move_send(job_count=20)'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://172.20.18.5:8069/web/assets/0604b65/web.assets_web.min.js:3140:163)
at XMLHttpRequest. (http://172.20.18.5:8069/web/assets/0604b65/web.assets_web.min.js:3145:13)



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

Let's say a Document Folder is shared with a portal user with 'edit' access. The portal user shares a .xlsx file to the folder, and an internal user later try to convert the file to odoo spreadsheet. During the conversion, the portal user has 'edit' role on the folder, which is copied to the documents.access records of the converted sheet. Since Odoo prevents Spreadsheets from being shared in edit mode to portal users, _check_spreadsheet() raises a Validation Error, even though the internal user has all the access rights.

To improve the user experience, this commit overrides `copy_data` of `documents.access` model to assign `view` access to portal users for an odoo spreadsheet.

Maybe we can extract the if-conditions, and make it an API to reduce repeated code, as the same logic is being used in `_check_spreadsheet()` on the same file.
However, looping through the copied vals_list only when handler is spreadsheet might have more value in terms of performance.

---

This commit enables .xlsx to spreadsheet conversion only for internal users.
The solution for portal users requires more complex implementation deserving its own review cycle, which is proposed in [PR #92134](https://github.com/odoo/enterprise/pull/92134)
(PR #92134's first commit is the same commit as current PR's commit)

opw-4753670

Steps to reproduce:
- Create an Account Group
- Create a new Account Report as follows:
  * Name: any
  * Lines:
    1. [test line]
      * Group By: partner_id,account_id
      * Expressions:
        1. [test expression]
          * Computation Engine: Odoo Domain
          * Formula: [('account_id.account_type', '=', 'asset_receivable')]
          * Subformula: sum
- Actions > Create Menu Item
- Open the new report
- Try to unfold/fold a partner line

Issue:
Folding will not fold the first child (representing the created account group). Also, error will raise
```
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90

Occured on odoo.nas.cpolar.cn on 2025-04-26 04:58:53 GMT

OwlError: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Error: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:138:49) (/web/static/lib/owl/owl.js:5752)
at App.callTemplate (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:11363:50) (/web/static/lib/owl/owl.js:3372)
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:9:12) (/web/static/lib/owl/owl.js:5752)
at RootFiber._render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9774:38) (/web/static/lib/owl/owl.js:1783)
at RootFiber.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9766:18) (/web/static/lib/owl/owl.js:1775)
at ComponentNode.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:10493:23) (/web/static/lib/owl/owl.js:2502)
```

Analysis:
Folding issues occurs because of a mismatch in the grouping markup quote escape. If we don't have the very same string the controller cannot properly recognize the parent line and then is unable to fold/unfold properly.
This eventually led to the mentioned error at unfold as the backend will try to generate the apparently missing lines to unfold, only to create duplicate lines

opw-4754241

### Steps to reproduce:
	- Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours.
	- Create a public holiday with generic time off work entry type.
	- Create one or multiple attendances for marc demo on the public holiday.
	- Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h.

### Cause:
This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day

### Fix:
We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day

opw-4887933

Steps to reproduce:
- Delete the mail template `GSTR-1 Exception`
- Accounting -> Reporting -> GST Return Period
- Create a return period, Under GSTR1 click Push to GSTN
- Click on the Check Status Button

The following RPC is produced:
```py
  File "/home/odoo/src/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1261, in button_check_gstr1_status
    self.check_gstr1_status()
  File "/home/odoo/src/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1345, in check_gstr1_status
    act_type_xmlid, advisor_user = self._get_gstr_responsible_activity_and_user()
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1271, in _get_gstr_responsible_activity_and_user
    act_type = self.env['mail.activity.type'].sudo()._load_records({
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/models.py", line 5439, in _load_records
    xml_ids = [data['xml_id'] for data in data_list if data.get('xml_id')]
                                                       ^^^^^^^^
AttributeError: 'str' object has no attribute 'get'
```

In this commit, we resolve the above issue and restore the expected output

task-5010701

Booking an appointment on the website creates a new contact. If the same user books again, a duplicate contact is created instead of reusing the existing one.
---

**Steps to Reproduce**

1. Book an appointment with a name, email, and phone.
2. Book a second appointment using the same data.
3. A new duplicate contact is created.

---

**Cause:**
In v18, the appointment booking flow lost the fallback email search mechanism that existed in v17. When `_get_customer_partner()` returns empty (anonymous users), the system immediately creates a new partner without checking if one already exists with the same email. This regression causes duplicate contacts to be created for repeat anonymous bookings.

**Root Issue:**
The v17 logic included an email search fallback:
```python
        customer = request.env['res.partner'].sudo().search([('email_normalized', '=', email_normalized)], limit=1)
```
This was removed in v18, breaking the partner reuse mechanism.

**Solution:**
Restore the email search logic with multi-company awareness:
1. **Email Search**: When no customer is found, search for existing partners by normalized email
2. **Company Boundaries**: Limit search to partners without a company or belonging to the current company context to prevent cross-company data conflicts
3. **Fallback Creation**: Only create new partners when no compatible existing partner is found

---

This fix restores the fallback email search logic from v17, ensuring anonymous users booking appointments reuse their existing contact records while maintaining proper company data isolation in multi-company environments.
 The search is limited to partners without a company or partners belonging to the current company to prevent cross-company data conflicts.

**opw-4614897**