Because it overrides the unlink of `IrModel` odoo/odoo#214315 breaks a ton of model uninstall/reinstall (basically all its dependencies, direct or transitive): when `marketing_card` is marked for uninstallation, all its fields get removed first (because that's how `_module_data_uninstall` does things), so all the non-magic columns are dropped.

Then, when trying to `unlink` the `ir.model` records the `unlink` call fails with some sort of "column does not exist" error (on `active` or `res_model`), the unlink fails, which leads the tables to not be removed, leaving a ton of garbage in the database.

This in turns means trying to reinstall the module also fails, as many tables will have a few records left for one reason or another before they are dropped, so new columns which are `required` without a `default` fail to set up their constraint, which logs both errors and warnings on reinstall.

None of this is necessary, if `marketing_card` is being uninstalled we can just ignore the entire issue as the table should be dropped eventually, even if it worked it would be a waste of time.

https://runbot.odoo.com/odoo/error/230837

Forward-Port-Of: odoo/odoo#222789

**Problem:**
when a MO is unbuild, if some components
where consigned, they will come back in stock as not consigned

**Steps to reproduce:**
- enable "consignemnet" setting
- create a storable product (the comp)
- set on on hand quantity of 3 without owner
- set on on hand quantity of 4 with an owner
- create another product (the final product), with a BOM of 7 of the comp product
- create a manufacturing order for the final product, confirm and produce all.
- unbuild it
- open the comp product form, click on the on hand smart button

**Current behavior:**
- there is a quantity of 7 unconsigned

**Expected behavior:**
- there should be a quantity of 3 unconsigned and a quantity of 4 consigned

**Cause of the issue:**
when the stock move line is create in action_unbuild() there is no mechanism to get back the owner of the original stock move line from the MO
https://github.com/odoo/odoo/blob/ceccb92af19a6a3fc0c7b5924d9f497b1aec1d55/addons/mrp/models/mrp_unbuild.py#L204

opw-4900386

Forward-Port-Of: odoo/odoo#222491
Forward-Port-Of: odoo/odoo#219905

[FIX] html_builder, *: use name for multiple checkbox form field
*: website

Steps to reproduce the problem:
- Add a form snippet on the website.
- Add a "Multiple Checkboxes" field in the form and change the name of a
checkbox.
- Make the first field depend on the "Multiple Checkboxes".

-> The name of the checkboxes are not correct.

When the user changes the name of a checkbox, there is a re-redendering
of the entire field. The problem here is double:
- The template used for the re-redendering is based on the `id`
attribute given as parameter to correctly set the `value` attribute of
the `input` of the checkbox. Since the [website refactoring], the
parameter was not not correctly computed as an unexplainable
`isFieldElCustom` condition was introduced. Due to it, the `value`
attributes of all the `input` checkboxes were wrongly set.
- The system was not updating the `id` attribute with the new user
value. Due to it, the system failed at setting the correct `value`
attribute of the renamed field.

----------------------------------------------------------------------------------------------------------------------------------------------------------


[FIX] html_builder, *: update value list on multiple checkbox add option
*: website

Steps to reproduce the problem:
- Add a form snippet on the website.
- Add a "Multiple Checkboxes" field in the form and make the first field
depend on this one ("Visible only if", "Custom Text", "Is equal to",
"Option 1").
- Click on "Add new Checkbox".
- Click on the first field and open the dropdown to try to change
"Option 1" to "Item" (the new checkbox).

-> The new checkbox is not in the list.

When the user adds a new checkbox, there is a re-redendering of the
entire field. The problem is that the template used for the
re-redendering is based on the `id` attribute given as parameter to
correctly set the `value` attribute of the `input` of the checkbox. This
commit re-introduces this parameter as it was missing when adding a new
checkbox since the [website refactoring].


----------------------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: refresh visibility option names
Steps to reproduce the problem:
- Add a form field on the website
- Add a "Multiple Checkboxes" field in the form and make the first field
depend on this one ("Visible only if", "Custom Text", "Is equal to",
"Option 1").
- Select "Option 1" and change its name.
- Click on the first field.

-> The UI shows "Visible only if", "Custom Text", "Is equal to", "None".

The problem is that since the [website refactoring], the update of
dependencies done when a field was replaced was missing.

Related to task-4367641

[website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

<b>Steps to reproduce:</b>
1. Install base_geolocalize and Contacts > Go to Contacts.
2. Create a new contact or select an existing one (Individual).
3. Go to Contacts & Addresses > Add, leave all fields empty, then Save & Close.
4. Open the newly created sub-contact > Partner Assignment > Geolocation
5. Click "Compute based on address".

<b>Issue:</b>
- Traceback is raised during geolocation computation if the sub-contact has no name Instead of Displaying.

<b>Cause:</b>
- If a partner does not have a name, the value is False.
- The join() operation results in a TypeError because False cannot be concatenated with strings.

<b>Problematic line:</b>
`'message': _('No match found for %(partner_names)s address(es).', partner_names=', '.join(partners_not_geo_localized.mapped('name')))`


<b>Solution:</b>
- Replaced `name` with `display_name` to ensure all elements passed to`join()` are strings.
This also improves readability in the UI when identifying partners without proper names.

opw-4930258

Forward-Port-Of: odoo/odoo#222317
Forward-Port-Of: odoo/odoo#218292

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

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

Forward-Port-Of: odoo/odoo#213900

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

Forward-Port-Of: odoo/odoo#221847

Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Google, when the synchronization of user A starts or resumes, the event will be synchronized with the user A as organizer in Google. In the meanwhile, in Odoo, the event ownership will be shown as user B, mismatching the organizer field between the two ends. This is problematic because the ownership of the event will be forever wrong in Google.

After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Google, it will be correctly synchronized in Google as well.

Recently, we had to revert this PR due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back.

task-4269432

Forward-Port-Of: odoo/odoo#219178
Forward-Port-Of: odoo/odoo#218856

Steps to reproduce the issue:

1. Create a calendar event (meeting, for example)

2. Set the start date as yesterday and in 30 minutes from now.

3. Set it to be recurrent every week with end_type set to end_date and in the future(1 month from now).

4. Add a reminder to the event (30 mins, for example) and ensure that calendar_last_notif_ack is set before the alarm window for your user's res.partner.

5. Save the event and observe an alarm notification made for an event in the past.

After the fix, the calendar alarms will only trigger for events in the future and in their designated time windows. The recurrence logic was also removed from the query to align with this [[REF]](https://github.com/odoo/odoo/pull/42031/commits/a27afdb5434166c3ea48c18ccfba9e8245d18e62) since
recurring events are all persistent records in the database.

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

Forward-Port-Of: odoo/odoo#222610
Forward-Port-Of: odoo/odoo#222214

## Issue: ##
A warning appears in Physical Inventory when transferring a product with a serial number between two locations

## Cause: ##
The `_compute_sn_duplicated()` method incorrectly considered `stock.quant` records with quantity 0
That mean that it will considered a duplication even if the quant indicate that the product isn't in that location

Additionally, the system parameter `stock.skip_quant_tasks` is enabled on all SaaS environments since version 18.2  
It was added for performance issues:
(see: https://github.com/odoo/odoo/commit/207ba01819577cf6a2a686fae39dd3d673aec6dd)
When enabled, the quant merging and removal of zero quants are skipped when opening a Physical Inventory, causing this issue to appear

## Steps to reproduce: ##
- Enable Developer Mode
- Create a New System Parameter (Key: stock.skip_quant_tasks, Value: True)
- In Settings, enable Storage Locations and Lots & Serial Numbers
- Duplicate WH/Stock as WH/Stock (copy)
- Create a product tracked by Unique Serial Number
- Update its quantity: one at WH/Stock
- Process an Internal Transfert from WH/Stock to WH/Stock (copy)
- Go in Operations > Adjustments > Physical Inventory

opw-4944011

Forward-Port-Of: odoo/odoo#221578

Commit https://github.com/odoo/odoo/commit/97fe24cea74241a7820841a470994d3ebf9d8d38 changed the engine for some report line of Modelo 111. The new engine used, `external`, is not compatible with having a grouping value defined by the user (field `user_groupby`). Except that value does not get removed from the report lines. As a result, a traceback pops up whenever we try to access the report.

Two previous commits aimed to sync that field with the `groupby` field (https://github.com/odoo/odoo/commit/a7d54c76aaee325449248fa698adb9e549c486ee), and update it if it was not compatible with the engine (https://github.com/odoo/odoo/commit/0d5bf820c3737ee3e4af54d1fb556b72d6c59c3d) but both only work with `aggregation` engine.

This commit makes `_validate_engine()` account for `external` engine, as it was only checking for `aggregation` engine when validating `groupby` related fields.

opw-4972212
opw-4971497
opw-4931269
opw-4949654

Forward-Port-Of: odoo/odoo#221407
Forward-Port-Of: odoo/odoo#221021

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#222390
Forward-Port-Of: odoo/odoo#222179

Issue
-----
Incoming return slips have a "Demo Address and Name" text instead of the correct destination address.
<img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" />

Steps to reproduce
-----
- Create a receipt for a product
- Print its return slip

Cause
-----
By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field.

Note
-----
To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see
https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016

With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it.

-----
Ticket:
opw-4660716

Forward-Port-Of: odoo/odoo#221807
Forward-Port-Of: odoo/odoo#219011

### Steps to reproduce:
	- Set timesheets inovicing policy to 'Validated Timesheets Only'
	- From the portal go to any task that has some validated timesheet and some other not
	- Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too

### Current behavior before PR:
The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account.

This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user

https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569

so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation.

### Desired behavior after PR is merged:
As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user.

opw-4193842

Forward-Port-Of: odoo/enterprise#70557

## [FIX] sale_renting_planning: make sure shift generated by RO is published

## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom

Before this commit, when the user creates room product to generate
shifts when a rental order is confirmed with that product, we expect to
generate one shift per quantity ordered if the UoM is Unit instead of
Hours/Days.

This commit improves the shifts generation to take into account the UoM
set on the SOL linked to rental order confirmed. That is, if the UoM set
is Unit then one slot per unit ordered of the product will be generated.
Otherwise, one shift will be generated for the SOL as it is currently
the case.

## [FIX] sale_renting_planning: make sure to not overload the rental service

Before this commit, when the user creates a new shift and clicks on `Add
to Last Order` the shift will be added to the SOL contained one of
products linked to the role set on the shift. The problem is we don't
check if there is still something to plan for that SOL.

This commit makes sure the SOL to set to the shift has something to plan
to be sure it is not overloaded.

task-4916537

**Issue**:
The expiration date displayed in the barcode app's scan screen may appear incorrect.

**Steps to reproduce**:

- Go to Settings > Inventory, and enable the `Expiration Date` field
- Open the Purchase app
- Create a new Request For Quotation
- Select a product that:
	- is a good tracked by lot
	- has the `Expiration Date` field enabled (Inventory tab > Traceability)
- Confirm the RFQ
- Click the `Receipt` smart button
- Click the `hamburger button` and enter an expiration date at midnight.
- Go to the Barcode application > Operation > Receipts
- Open the corresponding RFQ
- Click Edit and increase the quantity to 1, then Validate
- Observe that the date is displayed as one day earlier

**Cause**:
The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day.

**Solution**:
To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date.

opw-4865513

Forward-Port-Of: odoo/enterprise#91517
Forward-Port-Of: odoo/enterprise#88526