At confirmation page, we wait 500 ms before printing the order. That led to some problems when the user did not have a good network connection since the order was not yet initialized that the order would be printed and thus leading to an error. Here, if the order is not initialized yet, we reset a timeout to print the order runbot-error: 111762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199258 Forward-Port-Of: od

At confirmation page, we wait 500 ms before printing the order. That led to some problems when the user did not have a good network connection since the order was not yet initialized that the order would be printed and thus leading to an error.

Here, if the order is not initialized yet, we reset a timeout to print the order

runbot-error: 111762

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

Forward-Port-Of: odoo/odoo#199258
Forward-Port-Of: odoo/odoo#199050

Bug: At the moment, searching on `account.account` does not return accounts whose `company_ids` does not contain any of the companies accessible to the current user, even in sudo mode. Diagnosis: The default `_order` on `account.account` includes `placeholder_code`. When we call `_field_to_sql` for `placeholder_code`, we do a JOIN, which excludes any accounts for which a value could not be computed on `placeholder_code`. These are the accounts that are not accessible to the current user. S

Bug: At the moment, searching on `account.account` does not return accounts whose `company_ids` does not contain any of the companies accessible to the current user, even in sudo mode.

Diagnosis: The default `_order` on `account.account` includes `placeholder_code`. When we call `_field_to_sql` for `placeholder_code`, we do a JOIN, which excludes any accounts for which a value could not be computed on `placeholder_code`. These are the accounts that are not accessible to the current user.

Solution: We change `_field_to_sql` for `placeholder_code` to perform a LEFT JOIN rather than a JOIN on the first account company accessible to the user. If none of the account's companies are accessible to the user, `placeholder_code` will simply be NULL.

We add tests that check this behaviour and ensure that no accounts are excluded from a `search` in `sudo` mode.

opw-4393854

Forward-Port-Of: odoo/odoo#199310
Forward-Port-Of: odoo/odoo#198643

Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to. This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters. opw-4558352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od

Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to.

This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters.

opw-4558352

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

Forward-Port-Of: odoo/odoo#199288

Before this commit: ========== - Horizontal scroll for a navbar bar is not working as expected in the mobile view. After this commit: ========== - Horizontal scroll for a navbar bar will work fine, ensuring the navbar remains consistent on mobile devices. task-4550203 Forward-Port-Of: odoo/odoo#197478

Before this commit:
==========
- Horizontal scroll for a navbar bar is not working as expected in the mobile view.

After this commit:
==========
- Horizontal scroll for a navbar bar will work fine, ensuring the navbar remains consistent on mobile devices.

task-4550203

Forward-Port-Of: odoo/odoo#197478

In this commit, we adapt the unit tests to use macro.isComplete. In all these tests, what we want to verify in the end is that the macro or tour has performed as expected. This allows to remove all await advanceTime() or await animationFrame() and makes the tests much clearer. 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-

In this commit, we adapt the unit tests to use macro.isComplete. In all these tests, what we want to verify in the end is that the macro or tour has performed as expected. This allows to remove all await advanceTime() or await animationFrame() and makes the tests much clearer.

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

All these issues were spotted using the new irregularity map feature (task 4357729) Task: 4387232 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189835

All these issues were spotted using the new irregularity map feature (task 4357729)

Task: 4387232



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

Forward-Port-Of: odoo/odoo#189835

steps to reproduce: ------------------------ 1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in) 2. Enable the "Anglo-Saxon Accounting" option. 3. Migrate to 18.0 version. Issue: ------- Commit c2d0251 , sets a default value when changing the CoA. However, during migration, when the `_pre_load_data` function runs, it overrides the customer's selection even if the CoA is not changed and assigns the default value to the `anglo_saxon_account

steps to reproduce:
------------------------
1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in)
2. Enable the "Anglo-Saxon Accounting" option.
3. Migrate to 18.0 version.

Issue:
-------
Commit c2d0251 , sets a default value when changing the CoA. However,
during migration, when the `_pre_load_data` function runs, it overrides the 
customer's selection even if the CoA is not changed and assigns the default
value to the `anglo_saxon_accounting` field, ignoring the customer's preference.

**Original DB:**
```psql
bona_2515224=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  6 | Handful of Health Pvt Ltd - TN | t
  4 | Handful of Health Pvt Ltd - KA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  2 | Handful of Health Pvt Ltd - MH | t
  7 | Handful of Health Pvt Ltd - GA | t
  5 | Handful of Health Pvt Ltd - RJ | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```
**Without fix:**
```psql
bona_2515224_upg=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  1 | Handful of Health Pvt Ltd - DL | f
  2 | Handful of Health Pvt Ltd - MH | f
  3 | Handful of Health Pvt Ltd - UP | f
  4 | Handful of Health Pvt Ltd - KA | f
  5 | Handful of Health Pvt Ltd - RJ | f
  6 | Handful of Health Pvt Ltd - TN | f
  7 | Handful of Health Pvt Ltd - GA | f
  8 | Handful of Health Pvt Ltd - GJ | f
(8 rows)
```
**With fix:**
```psql
bona_2515224_18.0=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  7 | Handful of Health Pvt Ltd - GA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  4 | Handful of Health Pvt Ltd - KA | t
  2 | Handful of Health Pvt Ltd - MH | t
  5 | Handful of Health Pvt Ltd - RJ | t
  6 | Handful of Health Pvt Ltd - TN | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```

opw-4542300


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

Forward-Port-Of: odoo/odoo#198011

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#199256 Forward-Port-Of: odoo/odoo#199176

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#199256
Forward-Port-Of: odoo/odoo#199176

Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record. Steps to reproduce: - Ensure the Mexican localization is installed and properly configured. - Generate an invoice and sign it with the government (CFDI). - Create and sign a payment for the invoice. - Cancel the payment from the CFDI table. Current behavior: - Odoo cancels the move

Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record.

Steps to reproduce:
- Ensure the Mexican localization is installed and properly configured.
- Generate an invoice and sign it with the government (CFDI).
- Create and sign a payment for the invoice.
- Cancel the payment from the CFDI table.

Current behavior:
- Odoo cancels the move, but the related payment remains posted.

Expected behavior:
- The payment should also be canceled when the move is canceled.

This fix ensures that the associated payment is canceled correctly.

opw-4528910

Forward-Port-Of: odoo/odoo#198082

The code has been introduced initialy by: https://github.com/odoo/odoo/commit/4cbd6cc52cb96cc20d41974a37410a37fd9902f5 ...but since the override has been reverted in: https://github.com/odoo/enterprise/commit/4f77e313ee9e97164f3ffe0e492f8f036fa53c50 ... those hooks are no longer necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199460

The code has been introduced initialy by:
https://github.com/odoo/odoo/commit/4cbd6cc52cb96cc20d41974a37410a37fd9902f5

...but since the override has been reverted in:
https://github.com/odoo/enterprise/commit/4f77e313ee9e97164f3ffe0e492f8f036fa53c50

... those hooks are no longer necessary.

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

Forward-Port-Of: odoo/odoo#199460

`test_15_o2m` was trying to check the result of an `in` query with False and False/id, however the id provided was the parent of a leaf, which should not return the parent itself, while the assertion right after checks that the parent is present in the result. The test was passing as with demo data the first record in `leaves` didn't have a parent_id. Runbot Error 135019 Forward-Port-Of: odoo/odoo#199448

`test_15_o2m` was trying to check the result of an `in` query with False and False/id, however the id provided was the parent of a leaf, which should not return the parent itself, while the assertion right after checks that the parent is present in the result.
The test was passing as with demo data the first record in `leaves` didn't have a parent_id.

Runbot Error 135019

Forward-Port-Of: odoo/odoo#199448

Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-32

Steps to reproduce:
- Add an snippet.
- Click the "show/hide on desktop"  button of visibility option.
- Click on the little eye on the "hidden elements" section to have it displayed again.
- Go to mobile preview mode.
- Come back to desktop view by toggling off mobile preview button.
- An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view.

After this commit:
Empty overlays no longer appear when switching between preview modes.

task-3270034

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

Forward-Port-Of: odoo/odoo#198521
Forward-Port-Of: odoo/odoo#173328

Before this commit: ========== - The floating order dialog title was not translated due to the use of `title.translate` in the .js file. After this commit: ========== - The floating order dialog title will be translated. task-4576073 Forward-Port-Of: odoo/odoo#199381 Forward-Port-Of: odoo/odoo#198490

Before this commit:
==========
- The floating order dialog title was not translated due to the use of `title.translate` in the .js file.

After this commit:
==========
- The floating order dialog title will be translated.

task-4576073

Forward-Port-Of: odoo/odoo#199381
Forward-Port-Of: odoo/odoo#198490

this follows commit 0f9d262fb1de2ea4355fc3a6f6d0152e67ccd37e which forgot a few things to enable drag/dropping for fields that are in the view but because of their automatic addition by ir.ui.view when the field is used in an expression. opw-4578365 Forward-Port-Of: odoo/enterprise#80157

this follows commit 0f9d262fb1de2ea4355fc3a6f6d0152e67ccd37e which forgot a few things to enable drag/dropping for fields that are in the view but because of their automatic addition by ir.ui.view when the field is used in an expression.

opw-4578365

Forward-Port-Of: odoo/enterprise#80157

…cies Add a boolean field on hr.contract via studio. Then remove that field from the model. That last operation crashes because _compute_final_yearly_costs has a dynamic depends on it which take many fields of the model. While we don't want to exclude every custom fields (starting with "x_") to continue to allow sufficient extension points we do exclude studio fields specifically, because those are not meant to be used in a complex compute method. After this commit, there is no crash

…cies

Add a boolean field on hr.contract via studio. Then remove that field from the model. That last operation crashes because _compute_final_yearly_costs has a dynamic depends on it which take many fields of the model.

While we don't want to exclude every custom fields (starting with "x_") to continue to allow sufficient extension points we do exclude studio fields specifically, because those are not meant to be used in a complex compute method.

After this commit, there is no crash

opw-4503855

Forward-Port-Of: odoo/enterprise#78963

A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique. runbot-135304 [^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d Forward-Port-Of: odoo/enterprise#80224

A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique.

runbot-135304

[^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d

Forward-Port-Of: odoo/enterprise#80224

The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution. Traceback: (VALUES where removed for readability, there were 100 of them) ``` 2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "accoun

The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock.

Notes:
We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution.

Traceback: (VALUES where removed for readability, there were 100 of them)
```
2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "account_bank_statement_line"
SET "cron_last_check" = "__tmp"."cron_last_check"::timestamp, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (...), (...), (...), (...), ) AS "__tmp"("id", "cron_last_check", "write_date", "write_uid")
WHERE "account_bank_statement_line"."id" = "__tmp"."id"'
ERROR: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"

2025-01-27 12:00:39,277 3822296 ERROR openerp odoo.addons.base.models.ir_cron: Job 'Try to reconcile automatically your statement lines' (297) server action #4952 failed
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_cron.py", line 572, in _callback
    self.env.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 833, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6707, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6784, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4881, in _write_multi
    self.env.execute_query(SQL(
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 962, in execute_query
    self.cr.execute(query)
  File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 373, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"
```

task-id: 4393854

Forward-Port-Of: odoo/enterprise#80059

Before Commit: ---------------------------- - Quality checks only displayed the product name, making it difficult to distinguish between variants in the same transfer. After Commit: ----------------------------- - Quality checks now display variant details, ensuring clarity and reducing confusion when handling multiple variants of the same product. task-4478249 Forward-Port-Of: odoo/enterprise#77337

Before Commit:
----------------------------
- Quality checks only displayed the product name, making it difficult to distinguish between variants in the same transfer.

After Commit:
-----------------------------
- Quality checks now display variant details, ensuring clarity and reducing confusion when handling multiple variants of the same product.

task-4478249

Forward-Port-Of: odoo/enterprise#77337

…2025 Forward-Port-Of: odoo/enterprise#80170 Forward-Port-Of: odoo/enterprise#80030

…2025

Forward-Port-Of: odoo/enterprise#80170
Forward-Port-Of: odoo/enterprise#80030

As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states. task-4557365 Forward-Port-Of: odoo/enterprise#79684

As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states.

task-4557365

Forward-Port-Of: odoo/enterprise#79684

taskid: 4471762 Forward-Port-Of: odoo/enterprise#80150

taskid: 4471762

Forward-Port-Of: odoo/enterprise#80150

An error occurs when the system tries to access single values from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/71747a21cb5c68a8ab151434f85c822f30649aad/stock_barcode/models/res_config_settings.py#L14-L15 Traceback On Sentry: ``` ValueError: too many values to unpack (expected 1) File "odoo/orm/models.py", line 6073, in ensure_one _id, = self._ids ValueError: Expected singleton: res.config.settings(52, 53) File "odoo/http.py", line 2420, in __c

An error occurs when the system tries to access single values from multiple records at [1].

Link [1]: https://github.com/odoo/enterprise/blob/71747a21cb5c68a8ab151434f85c822f30649aad/stock_barcode/models/res_config_settings.py#L14-L15

Traceback On Sentry:

```
ValueError: too many values to unpack (expected 1)
  File "odoo/orm/models.py", line 6073, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.config.settings(52, 53)
  File "odoo/http.py", line 2420, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1946, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 2010, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1977, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2228, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 335, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 741, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 31, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/service/model.py", line 62, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "odoo/orm/models.py", line 3611, in read
    return self._read_format(fnames=fields, load=load)
  File "odoo/orm/models.py", line 3841, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/orm/models.py", line 6880, in __getitem__
    return self._fields[key].__get__(self)
  File "odoo/orm/fields.py", line 1428, in __get__
    self.compute_value(recs)
  File "odoo/orm/fields.py", line 1594, in compute_value
    records._compute_field_value(self)
  File "odoo/orm/models.py", line 5055, in _compute_field_value
    determine(field.compute, self)
  File "odoo/orm/fields.py", line 70, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-18.1/stock_barcode/models/res_config_settings.py", line 32, in _compute_show_barcode_nomenclature
    self.show_barcode_nomenclature = self.module_stock_barcode and self.env['barcode.nomenclature'].search_count([]) > 1
  File "odoo/orm/fields.py", line 1369, in __get__
    record.ensure_one()
  File "odoo/orm/models.py", line 6076, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```


To resolve this issue, Use an iteration(for loop) to iterate records one by one.

Sentry-6296116940

Forward-Port-Of: odoo/enterprise#79320

Forward-Port-Of: odoo/enterprise#75261

Forward-Port-Of: odoo/enterprise#75261

### Issue: - When we select a document and click on the "Info and tag" button, a traceback is thrown. ### Steps to reproduce: - Open the documents app - Preview a document - Click on the "Info and tag" in the "Action" dropdown menu - a traceback is thrown ### Solution: - When we click on the "Info and tag" button, `onToggleChatter` is called, in it we try getting the element of the selected document and scrolling to it, if the `querySelector` returns null, and we try to call `scrollI

### Issue:
- When we select a document and click on the "Info and tag" button, a traceback is thrown.

### Steps to reproduce:
- Open the documents app
- Preview a document
- Click on the "Info and tag" in the "Action" dropdown menu
- a traceback is thrown

### Solution:
- When we click on the "Info and tag" button, `onToggleChatter` is called, in it we try getting the element of the selected document and scrolling to it, if the `querySelector` returns null, and we try to call `scrollIntoView` on it, a traceback is thrown.
- we fixed this by adding the optional chaining operator `(?.)` to safely call scrollIntoView only if querySelector returns an element.
- although not directly related to the issue, we also added a small check to disconnect any previous `MutationObserver` before creating a new one.

OPW-4586089

Forward-Port-Of: odoo/enterprise#79975

Currently, a traceback is occurring when the user tries to create an exchange return without giving the origin value in picking. To reproduce this issue: 1) Install `purchase_stock` 2) Create a stock picking with operation type as `receipts` and don't give the `origin` value 3) Add a product in operation that contains vendor records in the product 4) `Validate` the product and click the `return` button to open a wizard 5) Update the qty to return and click the `Return for Exchange

Currently, a traceback is occurring when the user tries to create an 
exchange return without giving the origin value in picking.

To reproduce this issue:

1) Install `purchase_stock`
2) Create a stock picking with operation type as `receipts` and don't give the `origin` value 
3) Add a product in operation that contains vendor records in the  product
4) `Validate` the product and click the `return` button to open a wizard 
5) Update the qty to return and click the `Return for Exchange` button

Error:-
```
TypeError: sequence item 0: expected str instance, bool found
```

This traceback occurs from the line below because we are getting the origin value as False from the procurements.

https://github.com/odoo/odoo/blob/949ed6f30f539dd787594511751bda0e714a5409/addons/purchase_stock/models/stock_rule.py#L119

The origin value of this procurement is directly taken from the origin value of picking. 
The above traceback occurs because the user didn't provide the origin value in picking.

We can resolve this issue by providing a fallback value of an empty string if there is no origin in picking.

sentry-6316652948

Forward-Port-Of: odoo/odoo#198724