Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132 Forward-Port-Of: odoo/enterprise#75659

Steps to reproduce
==================

- Archive default "Projects" workspace
- Create a new Project
- Create a task and attach a file
- Click on the smart button to view the document
- Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')`

Solution
========

Prevent the archiving of the projects workspace

opw-4308132

Forward-Port-Of: odoo/enterprise#75659

**Issue:** Some tax reports don't display all data. Last columns may be cropped.  **Expected:** The PDF file should contain all data displayed in the Tax Report table view as is. **Steps to reproduce:** - Activate Accounting app; - Install the Argentina localization; - Move to the Argentine company; - Go to `Accounting` > `Reporting` > `Tax Report`; - Change se

**Issue:**
Some tax reports don't display all data. Last columns may be cropped.
![Capture d’écran 2024-12-06 à 09 55 34](https://github.com/user-attachments/assets/1da85555-fe2f-434c-bdd5-789838960f0e)

**Expected:**
The PDF file should contain all data displayed in the Tax Report table view as is.

**Steps to reproduce:**
- Activate Accounting app;
- Install the Argentina localization;
- Move to the Argentine company;
- Go to `Accounting` > `Reporting` > `Tax Report`;
- Change selection to display some lines (or add invoice lines);
- Print PDF report.

**Cause:**
The columns are cropped because of the global width of the report wkhtmltopdf can't handle correctly.

**Fix:**
Remove useless currencies' display in headers.
Backport improvement (https://github.com/odoo/enterprise/commit/5bbdc059045c1a50c8ef1d6f5f8c9cb76d2d85f9).
![Capture d’écran 2024-12-06 à 09 56 38](https://github.com/user-attachments/assets/83e80f24-d1fb-45e5-88c7-8e9303b987ca)

Ticket link: https://www.odoo.com/odoo/project/967/tasks/4349604
opw-4349604

Forward-Port-Of: odoo/enterprise#75259

Steps to reproduce: - Install helpdesk_stock and Studio - Create 3 contacts, 1 company and two child employees - Create a quotation for each contact with a different product - Helpdesk app > Create a ticket - Add the Product ('product_id') field with studio - (Under 'Existing Fields' search product) - (View tab > Show invisible elements > Find product field > untick invisible) The products from contacts linked to the parent company should appear, but only those related to SOs from the

Steps to reproduce:
- Install helpdesk_stock and Studio
- Create 3 contacts, 1 company and two child employees
- Create a quotation for each contact with a different product
- Helpdesk app > Create a ticket
- Add the Product ('product_id') field with studio
- (Under 'Existing Fields' search product)
- (View tab > Show invisible elements > Find product field > untick invisible)

The products from contacts linked to the parent company should appear, but only those related to SOs from the contact itself or its parent company are shown (i.e. We should see all 3 products no matter which contact is set as customer).

This is related to https://github.com/odoo/enterprise/pull/73391, which was a step in the right direction but still insufficient. Unlike that fix however this one is relevant up to master.

opw-4285382

Forward-Port-Of: odoo/enterprise#74361

Steps: - Go to the Rewards page - Buy a reward - Breadcrumb and navigation menu were disappearing after the purchase Cause of the issue: - Page reload was resetting the breadcrumb and navigation Fix: - Used a soft reload instead of a full page reload to prevent the reset and preserve the breadcrumb and navigation menu task-4266538 Forward-Port-Of: odoo/enterprise#74445

Steps:
- Go to the Rewards page
- Buy a reward
- Breadcrumb and navigation menu were disappearing after the purchase

Cause of the issue:
- Page reload was resetting the breadcrumb and navigation

Fix:
- Used a soft reload instead of a full page reload to prevent the reset and preserve the 
  breadcrumb and navigation menu

task-4266538

Forward-Port-Of: odoo/enterprise#74445

Scenario: - install account without commit (eg. before 3 december 2024): odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221 - install account_accountant with commit (eg. after 3 december 2024): e4111ac8f817f97b3d6128453659a1014b6db00f => Traceback with odoo.tools.convert.ParseError: while parsing account_accountant/views/product_views.xml:3 Field 'is_coa_installed' used in attrs ({'invisible': [('is_coa_installed', '=', False)]}) must be present in view but is missing.

Scenario:

- install account without commit (eg. before 3 december 2024): odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221
- install account_accountant with commit (eg. after 3 december 2024): e4111ac8f817f97b3d6128453659a1014b6db00f

=> Traceback with odoo.tools.convert.ParseError: while parsing
   account_accountant/views/product_views.xml:3
   Field 'is_coa_installed' used in attrs
   ({'invisible': [('is_coa_installed', '=', False)]}) must be present
   in view but is missing.

Cause:

The change in account_accountant
(e4111ac8f817f97b3d6128453659a1014b6db00f) relies on the change in account (odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221) but account_accountant can be installed/updated without updating account.

Fix:

Add a duplicate is_coa_installed field in account_accountant useful if account module is not up to date.

opw-4323694

note: only useful up to saas-17.2, in saas-17.4 the field is automatically added if it's necessary for an attribute.

pr note: issue found when working on an unrelated ticket

Forward-Port-Of: odoo/enterprise#75490

**Issue:** - Uninstalling the Field Service app will make all normal projects non-billable, resulting in the removal of customers and sales orders from their tasks. **Steps To Reproduce:** - Install the Field Service app. - Create a project and set it as billable. - Create a task for the project. set customer and sales order. - Uninstall the Field Service app. - Check the project's billable status and the task. **Solution:** - remove the `uninstall_hook` meth

**Issue:**
    - Uninstalling the Field Service app will make all normal projects non-billable, resulting in the removal of customers and sales orders from their tasks.

**Steps To Reproduce:**
    - Install the Field Service app.
    - Create a project and set it as billable.
    - Create a task for the project. set customer and sales order.
    - Uninstall the Field Service app.
    - Check the project's billable status and the task.

**Solution:**
- remove the `uninstall_hook` method since the original issue it was added for is no longer reproducable. https://github.com/odoo/enterprise/pull/32022/commits/341e68e6a3e569137aeb41d69203c731559f9ef8

opw-[4379638](https://www.odoo.com/web#id=4379638&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#75356

Description of the issue this commit addresses: The community commit linked to this one changed the rates of luxembourgian taxes used in the oss fiscal positions. Because of that, some tests are failing. --- Desired behavior after this commit is merged: Said tests are not failing anymore. --- Community PR: https://github.com/odoo/odoo/pull/189444 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/enterprise#75716 Forward-Port-Of: odoo/en

Description of the issue this commit addresses:

The community commit linked to this one changed the rates of luxembourgian taxes used in the oss fiscal positions. Because of that, some tests are failing.

---

Desired behavior after this commit is merged:

Said tests are not failing anymore.

---

Community PR: https://github.com/odoo/odoo/pull/189444
task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658)

Forward-Port-Of: odoo/enterprise#75716
Forward-Port-Of: odoo/enterprise#75650

When creating a PO/SO with inter-company rules, the related SO/PO has no fiscal position set, unless having one set on the partner. Removing the `fiscal_position_id` from the values dict allows it to be computed directly at the creation of the related SO/PO Steps: - Have 2 companies A and B - Activate inter-company rules and synchronize sale/purchase orders - With A, create a SO for B, confirm - With B, go to PO and select the related PO newy created -> There is no fiscal position opw-4247948

When creating a PO/SO with inter-company rules,
the related SO/PO has no fiscal position set, unless having one
set on the partner.
Removing the `fiscal_position_id` from the values dict allows it to be
computed directly at the creation of the related SO/PO

Steps:

- Have 2 companies A and B
- Activate inter-company rules and synchronize sale/purchase orders
- With A, create a SO for B, confirm
- With B, go to PO and select the related PO newy created
-> There is no fiscal position

opw-4247948

Forward-Port-Of: odoo/enterprise#73392

Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is correctly computes the number of QC linked with finished_lot or lot_id thanks to: htt

Steps to reproduce the bug:
- Create a storable product “P1”:
   - Tracked with SN
   - Create a BoM:
       - no need to component
       - Add an operation “OP1” with steps
           - Control by product

- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1

Problem:
The quality check smart button is correctly computes the number of QC linked with finished_lot or lot_id thanks to:
https://github.com/odoo/enterprise/pull/72693/commits/2e2a49d4ee90b20fe899ca3c199a20ad88d185ad

but they are not read in the quality check view because the domain is
not correct

opw-4361358

Forward-Port-Of: odoo/enterprise#75447

**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722 Forward-Port-Of: odoo/enterprise#74938

**[FIX] account_consolidation: handle empty totals when formatting account lines**

When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash.

This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data.

opw-4205722

Forward-Port-Of: odoo/enterprise#74938

Currently, when reducing the quantity of a line, the notification for the cancelled items is not sent Steps to reproduce: ------------------- * Set up the preparation display on the category food * Open both restaurant and preparation display * In the restaurant place an order for an item with a quantity of 3 * Send the order to the kitchen * Change the quantity to 2 * Send the order to the kitchen > Observation: The notification is not sent to the preparation display Why the fix:

Currently, when reducing the quantity of a line, the notification for the cancelled items is not sent

Steps to reproduce:
-------------------
* Set up the preparation display on the category food
* Open both restaurant and preparation display
* In the restaurant place an order for an item with a quantity of 3
* Send the order to the kitchen
* Change the quantity to 2
* Send the order to the kitchen
> Observation: The notification is not sent to the preparation display

Why the fix:
------------
When reducing the quantity, data looks like this
`{'change': True, 'sound': False, 'category_ids': {}}`. Since `category_ids` is empty, `preparation_displays` will alsos be empty which explains why the preparation display does not receive the notification, it is simply not sent.
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/preparation_display_order.py#L29-L40

When augmenting the quantity we add the category here: https://github.com/odoo/enterprise/blob/681c4bca67e9e312f66d797e45fb7e1c3a10b983/pos_preparation_display/models/pos_order.py#L135

We use the same logic when reducing it. This is already done in more recent version:
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/pos_order.py#L166

opw-4332578

Forward-Port-Of: odoo/enterprise#74803

This commit upgrades the Linkedin's versioned API to the latest available which is `202411`. As no features has been broken, nor is there any new features impacting the parts of the API we use. Only the headers are updated as explained inside their documentation. task-4273179 Forward-Port-Of: odoo/enterprise#74687

This commit upgrades the Linkedin's versioned API to the latest available which is `202411`.

As no features has been broken, nor is there any new features impacting the parts of the API we use. Only the headers are updated as explained inside their documentation.

task-4273179

Forward-Port-Of: odoo/enterprise#74687

Steps to Reproduce: - Install the Helpdesk app without demo data. - Navigate to the dashboard. - Observe the `SAMPLE` ribbon in the top-right corner. Cause: - The issue occurs because the SAMPLE ribbon for "Fake Data for Demo" is rendered before the helpdesk banner. Due to this loading order, the banner displays on top of the ribbon, obscuring it. Solution: - By adjusting the loading order so the ribbon loads after the helpdesk banner, we ensure the ribbon displays clearly

Steps to Reproduce:
- Install the Helpdesk app without demo data.
- Navigate to the dashboard.
- Observe the `SAMPLE` ribbon in the top-right corner.

Cause:
- The issue occurs because the SAMPLE ribbon for "Fake Data for Demo" is 
  rendered before the helpdesk banner. Due to this loading order, the banner 
  displays on top of the ribbon, obscuring it.

Solution:
- By adjusting the loading order so the ribbon loads after the helpdesk banner, 
  we ensure the ribbon displays clearly above the banner without additional 
  adjustments.


task: 4209920

Forward-Port-Of: odoo/enterprise#72786

An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n

An error occurs when the system try to raise an error message when a bank account has not client code.

```TypeError: list.append() takes no keyword arguments```

Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error.

Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n_jp_zengin/models/account_batch_payment.py#L77

Sentry-6128197646

Forward-Port-Of: odoo/enterprise#75475

Before this commit there was no groupby Properties. In this commit we add a filter for groupby properties in planning module. The search view is being used by two modules`planning.slot` and `planning.analysis.report` thus solution resulted in adding the filter in `planning_view_search` as it is a primary inherited view of search view base in planning.slot. task-3801551 Forward-Port-Of: odoo/enterprise#58814

Before this commit there was no groupby Properties.

In this commit we add a filter for groupby properties in planning module.
The search view is being used by two modules`planning.slot` and
`planning.analysis.report` thus solution resulted in adding the filter in
`planning_view_search` as it is a primary inherited view of search view base in
planning.slot.

task-3801551

Forward-Port-Of: odoo/enterprise#58814

Community: https://github.com/odoo/odoo/pull/189421 task-4374458 Forward-Port-Of: odoo/enterprise#75671

Community: https://github.com/odoo/odoo/pull/189421

task-4374458

Forward-Port-Of: odoo/enterprise#75671

When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines

When loading the Profit and Loss report with multiple analytic filters, loading times can be very slow on larger databases. Analytic filtering necessitates the creation of a temporary table which is used to merge the account_move_line and account_analytic_line tables. This process takes an enormous amount of time on large databases and is unnecessary. Since this table is created whenever the analytic filters are changed (it is dropped on commit), it is much faster to only copy the relevant lines into the new table. This PR adds logic to identify the relevant analytic accounts for the given query, and changes the table-making query to only copy lines with the relevant analytic accounts attached to them.

Performance Benchmarks Pre:
| 100,000 lines | 250,000 lines| 500,000 lines|
|--------|--------|--------|
| 5.2s | 10.77s | 110s |
| 4.86s | 11.43s | 110s |
| 5.16s | 12.2s | 115s |

Performance Benchmarks Post:
| 100,000 lines | 250,000 lines | 500,000 lines |
|--------|--------|--------|
| 1.56s | 3.19s | 6.22s |
| 2.65s | 6.03s | 11.58s |
| 3.74s | 8.36s | 16.36s | 

OPW-4300365

Forward-Port-Of: odoo/enterprise#73769

In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190748 Forward-Port-Of: odoo/odoo#190693

In January 2025, Indonesia is increasing their
tax rate from 11% to 12%.
This commit adds a new 12% tax as well as the upgrade script to load it into existing databases.

task id # 4409300

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

Forward-Port-Of: odoo/odoo#190748
Forward-Port-Of: odoo/odoo#190693

### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU, non-EU countries, ...) it is perfectly valid to have a VAT that doesn't follow this format. To avoid the rule to raise, we should set the tax scheme ID to something else than "VAT". ### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries BIS3 is an electronic for

### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID
Rule [BR-CO-09] enforce the VAT number to start with a country code
if the tax scheme id is "VAT".
In some countries (RO, HU, non-EU countries, ...) it is perfectly valid
to have a VAT that doesn't follow this format.
To avoid the rule to raise, we should set the tax scheme ID to something
else than "VAT".

### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries
BIS3 is an electronic format closely related to Peppol.
It therefore only make sense to enable it by default on partners
that are in countries where it's actively used or will become
mandatory soon.

### [FIX] account_edi_ubl_cii,base_vat,l10n_hu: VAT conversion to EU format
Hungary may have different format of VAT number.
It is possible to convert their local format (xxxxxxxx-y-zz) to the EU
format (HUxxxxxxxx).
We should use this converted format when computing the Peppol Endpoint.

Enterprise: https://github.com/odoo/enterprise/pull/75671

task-4374458

Forward-Port-Of: odoo/odoo#189421

## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants. ## Patch Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, be

## Description
When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants.

## Patch
Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, before looping.
- Lift `exists` check outside the loop, it does 1 query.
- Batch the `search` in the main loop body of `product.product`'s `unlink` with a `_read_group`.
- Replace usage of `recordset`'s `union` with `set`'s `add`, due to the loop, complexity goes from `O(n^2)` -> `O(n)` for `n := len(self)`.

## Benchmark
On a DB with 1.2M `product.product`, adding a new PTAV to a `product. template` with 39k+ variants takes:

|         | Before             | After  |
|---------|--------------------|--------|
| Timings | timeout (ETC 3h+)* | 2.2min |

\* - ETC was calculated by extrapolating the search query in the loop, which was taking ~300ms, times the number of variants to be unlinked which was 39k+ variants.

## Reference
opw-4383294

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

Forward-Port-Of: odoo/odoo#190739

The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the st

The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`.

This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules.

This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the start of the working day.





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

Forward-Port-Of: odoo/odoo#189983

Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% ---

Description of the issue this commit addresses:

Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping.

---

Desired behavior after this commit is merged:

Rates that had been diminished by 1% are back to their original value.
16% -> 17%
7% -> 8%

---

Enteprise PR: https://github.com/odoo/enterprise/pull/75650
task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658)

Forward-Port-Of: odoo/odoo#190816
Forward-Port-Of: odoo/odoo#189444

### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive "Replenish on Order (MTO)" - Create a storable product P with routes: MTO, Buy and a set vendor - Create and confirm a sale order with one line: - 2 x product P > A delivery has been created. - Cancel the SO, set it back to quotation and confirm it once more. > The first delivery has been cancelled and a new one has been created - Decrease the quantity of the SOL from 2 to 1 and save ####

### Steps to reproduce:

- In Settings, enable "Multi-Step Routes"
- In the Routes, unarchive "Replenish on Order (MTO)"
- Create a storable product P with routes: MTO, Buy and a set vendor
- Create and confirm a sale order with one line:
    - 2 x product P
> A delivery has been created.
- Cancel the SO, set it back to quotation and confirm it once more.
> The first delivery has been cancelled and a new one has been created
- Decrease the quantity of the SOL from 2 to 1 and save
#### > Issue: The delivery from stock to customer was not updated but an incoming picking was created from customer to stock.

### Cause of the Issue:

When confirming the SO, `_run_pull` will be called and will create an outgoing move SM01 based on our rule. Initially and because of the rule used for its creation, the `procure_method` of this move is `make_to_order`. However, once the SO is cancelled, this move `procure_method` will be updated to be `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1794-L1798 Once the SO is reset to draft and confirmed once more, a new outgoing move SM02 will be created by the `_run_pull` using the same rule as SM01 Then, when the quantity of the SOL is decreased from 2 to 1, a negative outgoing move SM03 will be created by the `_run_pull` and is expected to be absorbed by SM02 during the `_merge_move` of its `action_confirm`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1397

However, the merging process will fail for 2 reasons:

1. Negative moves are merged based on a reduced set of comparaison keys: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1046-L1047 Which is expected to exculde the created sale order lines: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/purchase_stock/models/stock_move.py#L28 However, the field name `created_purchase_line_id` has been renamed to `created_purchase_line_id"s"` in 17.0 and this update has been reased by mistake during a forward port: b40bd15c9ce43b60a8993afbe61c56a3bb9f782f

2. While the `procure_method` is a valid comparaison key for negative moves, it is a tricky field to use as the `procure_method` present on the move we want to merge with might not correspond to the `procure_method` set by our rule (`make_to_order` for SM03). The purpose of these lines is therefore to update the `procure_method` of negative moves to match valid merging candidates:
https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L260-L269 However, SM01 is not a valid merging candidtes as it was cancelled and its `procure_method` has changed during its cancellation so that it will wrongly update the `procure_method` of SM03 to `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L267-L268 and will therefore not match its only valid merging candidate: SM02.

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

Forward-Port-Of: odoo/odoo#190820

Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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 guid

Steps to reproduce:

- Insert a pivot in a spreadsheet (e.g. CRM Lead)
- Create a global filter, set a value on it (filter on CRM Stages -> Select new)
- Open the pivot side panel, update something (move up a dimension)
- Save => The domain does not take the global filter into account

Task: 4398645

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#190848
Forward-Port-Of: odoo/odoo#190781

### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put hal

### Initial issue:

On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location

### This issue was fixed in:
- 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7
- saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36

However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2:
If you were to put half of a lot in a pack in a sublocation and the other half eslewhere, the current fix of saas-17.2 would not use the sublocation that is however available as it relies on the 'location_id' field of the `stock.lot` model which will not be set in that valid use case:
https://github.com/odoo/odoo/blob/d9cca6201a39c431deaf13891a314dde2db7e82e/addons/stock/models/stock_lot.py#L155-L159

The purpose of the present PR is to reconcile both fix by reverting the current one and by adapting the test to both usecases.

Revert "[FIX] stock: start SML from sub location"

This reverts commit https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36.

X-original-commit: https://github.com/odoo/odoo/commit/28f5b2244954a8aaa2a7c2599b0716c88a55e5f0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#188840

We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#188512

We get an access error when trying to register
a vendor payment with a user having access only to a branch
company.

Steps:

- Create a branch B
- Create a user U with company_id and company_ids being B
- Log as user U
- Create and confirm a vendor bill
- Open the 'Register payment' wizard and try to create a payment
-> Access Error on company id

opw-4317289

Forward-Port-Of: odoo/odoo#188512

The import origin of `json` will be changed to `odoo.tools.safe_eval` for 2 reasons: 1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method. 2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`). follow up of: https://github.com/odoo/odoo/pull/187708 more info: https://git

The import origin of `json` will be changed to `odoo.tools.safe_eval`
for 2 reasons:

1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method.

2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`).

follow up of: https://github.com/odoo/odoo/pull/187708
more info: https://github.com/odoo/odoo/commit/5ef4c07ada1b47cd08a0fc7a2dd626f92d79b715#diff-6e39afafc5c2078cdfdc27335b7cf8b0867853dc34b5b907a0190f6453949bb2R21
opw-4187186

Forward-Port-Of: odoo/odoo#190955