Steps to reproduce: - Create a product that is a kit in company A and not in company B - Try updating quantity on hand in company B Bug: since [1] it's not possible to update kit quantites directly but is_kits is not company dependant Fix: is_kits depends on the selected companies opw-3946361 [1]:https://github.com/odoo/odoo/pull/161124/files Forward-Port-Of: odoo/odoo#174233 Forward-Port-Of: odoo/odoo#169063

Steps to reproduce:
- Create a product that is a kit in company A and not in company B
- Try updating quantity on hand in company B

Bug:
since [1] it's not possible to update kit quantites directly but is_kits is not company dependant

Fix:
is_kits depends on the selected companies

opw-3946361
[1]:https://github.com/odoo/odoo/pull/161124/files

Forward-Port-Of: odoo/odoo#174233
Forward-Port-Of: odoo/odoo#169063

This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled. **Steps to reproduce:** - Install Sales & Accounting - Create a second company with a different currency (e.g. AED) than the first one (e.g. USD) - Configure the rounding factor of the currency of the second company to 1.000000 - Configure the default company of the curre

This is a complement to previous fix https://github.com/odoo/odoo/commit/649a7f185dca806af3b3d54a1e4390b9baff79c6 in which the use case where both companies have "Round Globally" set as "Rounding Method" was not handled.

**Steps to reproduce:**
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part
- Save the SO

**Issue:**
In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details.

opw-3814058



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

Forward-Port-Of: odoo/odoo#174560

[FIX] website_crm_partner_assign: fix sitemap grades Context: when visiting the `/partners` url, the user has access to the "silver", "gold" and "platinum" grades. However, when generating the sitemap, the `/partners/grade/bronze-4` url is part of it but trying to access it leads to a 404 server answer. Another problematic behavior is that if the user deactivates a grade ("gold" for example), the grade is still accessible from `/partners` (but the `/partners/grade/gold-2` url is not on

[FIX] website_crm_partner_assign: fix sitemap grades

Context: when visiting the `/partners` url, the user has access to the
"silver", "gold" and "platinum" grades. However, when generating the
sitemap, the `/partners/grade/bronze-4` url is part of it but trying to
access it leads to a 404 server answer. Another problematic behavior is
that if the user deactivates a grade ("gold" for example), the grade is
still accessible from `/partners` (but the `/partners/grade/gold-2` url
is not on the sitemap anymore).

This can be explained as:
- When visiting the `/partners` url, the `partners` route searches for
grades from `request.env['res.partner']`. By doing so, it ensures that
grades are linked to at least one partner; this explains why the
"bronze" grade (not linked to any partner) is not shown at the
`/partners` url and why the deactivated "gold" grade is still
accessible (as a partner is still related to it).
- When the user tries to reach a `/partners` route, a 404 server answer
is returned if no partners are found for the route (e.g.
`/partners/grade/bronze-4`).
- When generating the sitemap, the system is searching for grades from
`env['res.partner.grade']`. Due to it, inactive grades (e.g. "gold") are
not shown on the sitemap and grades that are not linked to a partner
(e.g. "bronze") are shown on the sitemap.

The goal of this commit is to:
- Correct the `/partners` route so that it does not show inactive
grades.
- Generate the sitemap coherently from what is done in the `/partners`
route.

In the end, the `/partner` route only shows company website published
partners linked to active website published grades. The user has then
the possibility to filter the partners by grades or by country.

opw-3992340

Forward-Port-Of: odoo/odoo#174250
Forward-Port-Of: odoo/odoo#170582

Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies. This fix adjusts the decimal places sent to Mollie according to the currency. opw-4011259 Forward-Port-Of: odoo/odoo#174278 Forward-Port-Of: odoo/odoo#173595

Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies.

This fix adjusts the decimal places sent to Mollie according to the currency.

opw-4011259

Forward-Port-Of: odoo/odoo#174278
Forward-Port-Of: odoo/odoo#173595

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. The monkeypatch is a full copy of the original code except for adding `operational_timeout` to the `Transport` initialization. The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded. Related zeep github issue: https://github.com/mvantellingen/

`stdnum` library incorrectly sets `zeep` `Transport` timeout, resulting in
some requests hanging for 15 minutes. With this monkeypatch the timeout
will be set correctly. The monkeypatch is a full copy of the original
code except for adding `operational_timeout` to the `Transport` initialization.

The monkeypatch can be removed when https://github.com/arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded.

Related zeep github issue: https://github.com/mvantellingen/python-zeep/issues/140
This fix was already merged but reverted due to an unexpected side-effect:
Original commit: https://github.com/odoo-dev/odoo/commit/11062f6f77ed1292c6db9d64985dddeb46d354c8
Revert: https://github.com/odoo-dev/odoo/commit/de9df2ba5c15d399d6906ef54f3e4ac9f063a175

The issue originated from a dependency issue in the `zeep` library in [Ubuntu 22.04](https://packages.ubuntu.com/jammy/python3-zeep).
The `python3-platformdirs` dependency is missing in there, yet it is used in that version of `zeep`. This missing dependency used to be hidden by the [chains of `try ... except ImporError` of `stdnum`](https://github.com/arthurdejong/python-stdnum/blob/d5666b8bfe379688a38bb0fd6764a8c536dd3c75/stdnum/util.py#L254).
That means that it's another import from the chain that was used. So to reduce the possibility of introducing a similar bug and catch such errors, the original code from `get_soap_client` of `stdnum` has been fully copied.

opw-3980718

Forward-Port-Of: odoo/odoo#174199
Forward-Port-Of: odoo/odoo#173359

Steps to reproduce: - Edit any product's 'Description for delivery orders' (inventory tab) - Create a delivery for this product (or confirm sale order to create one automatically) - Print delivery slip (Correct formatting) - Validate delivery - Print delivery slip once more (Description loses linebreaks) This is only for looks, but it's a document the end user will see so there are concerns about it looking unprofessional. This formatting error is due to us not being able to use a fie

Steps to reproduce:
- Edit any product's 'Description for delivery orders' (inventory tab)
- Create a delivery for this product (or confirm sale order to create one automatically)
- Print delivery slip (Correct formatting)
- Validate delivery
- Print delivery slip once more (Description loses linebreaks)

This is only for looks, but it's a document the end user will see so there are concerns about it looking unprofessional.

This formatting error is due to us not being able to use a field element after remaking the order lines to group related products in python.

opw-4040127

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

Forward-Port-Of: odoo/odoo#174495

Before this commit, when calling `_getSaveLineCommand` to get the save commands for the move lines, we do each line one by one, in the order where they were marked as to save, which means we can have an update command followed by a create command, itself followed by another update command for example. In the module `stock_barcode_picking_batch`, we add the test `test_barcode_batch_scan_lots`. In this test, we got a situation where we will write on the batch a command like that: ```python

Before this commit, when calling `_getSaveLineCommand` to get the save commands for the move lines, we do each line one by one, in the order where they were marked as to save, which means we can have an update command followed by a create command, itself followed by another update command for example.

In the module `stock_barcode_picking_batch`, we add the test `test_barcode_batch_scan_lots`. In this test, we got a situation where we will write on the batch a command like that:

```python
{
    'move_line_ids': [
        [UPDATE command],
        [CREATE command],
        [UPDATE command],
        [CREATE command],
        [CREATE command]
]}
```
The 2 first commands are for the move lines in the first batch's picking. The 3 last commands are for the move lines i the second batch's picking.

The issue is, the first CREATE command won't happen. The two move lines for the second picking will be created but the move line who should be created for the first commit will not.

It fails because the compute has a depends on himself. And it's recomputed on picking_ids that have a different cache than the batch. So the second UPDATE will trigger the compute that will rewrite the move_line_ids fields and cancel the first CREATE. So it means every CREATE commands before the last UPDATE will be ignored

Enterprise PR: odoo/enterprise#65182

Forward-Port-Of: odoo/odoo#173521

[FIX] web_editor: won't place font element between if else nodes Previously when we updated color on multiple selected nodes, </font> tag would get inserted between qweb if and else tags. This caused qweb processor to crash. After this change we don't insert font on the "t" elements. [Reproduce] - Install account - Open Email Template called "Invoice: Sending" - Change color of all of its content - Open preview opw-3912434 Forward-Port-Of: odoo/odoo#173703 Forward-Port-Of: odoo

[FIX] web_editor: won't place font element between if else nodes

Previously when we updated color on multiple selected nodes, </font> tag
would get inserted between qweb if and else tags. This caused qweb processor to crash.

After this change we don't insert font on the "t" elements.

[Reproduce]
- Install account
- Open Email Template called "Invoice: Sending"
- Change color of all of its content
- Open preview

opw-3912434

Forward-Port-Of: odoo/odoo#173703
Forward-Port-Of: odoo/odoo#169678

Avoid extra redirect, use slug directly instead. Forward-Port-Of: odoo/odoo#174032

Avoid extra redirect, use slug directly instead.

Forward-Port-Of: odoo/odoo#174032

Due to introduction of downpayment mechanism, if downpayment was made, Sale Order would no longer be in "has to be payed" state and it would prevent client from further payments. opw-3891128 Forward-Port-Of: odoo/odoo#163178

Due to introduction of downpayment mechanism, if downpayment was made,
Sale Order would no longer be in "has to be payed" state and it would
prevent client from further payments.

opw-3891128

Forward-Port-Of: odoo/odoo#163178

This update removes an unnecessary internal text conversion in the website generation area. It keeps the code simpler and easier to maintain without changing how users create or manage website pages.

This update simplifies internal text conversion logic across several Odoo Enterprise apps and removes an outdated helper where it was no longer needed. It also fixes menu icon handling so text-based icon data is not decoded incorrectly, improving reliability without changing user workflows.

This fixes a timing issue in the Knowledge sidebar test by waiting until a button is ready before using it. The change helps prevent false test failures, supporting smoother maintenance and more reliable releases.

We wait until the button is enabled before clicking on it.

Cashiers can now switch between email, WhatsApp, and SMS on the receipt screen without losing manually entered contact details. This reduces retyping and helps avoid checkout delays when customer records are missing or incomplete.

Before this commit:
====================
When switching the send options (email, WhatsApp, SMS) on the receipt screen, any manually entered input (such as email or phone number) would be erased if a customer was not selected or if customer data (email or mobile number) was not present.

Example:
Enter an email address manually.
Switch the send option to WhatsApp or SMS.
The manually entered email address would be erased.

After this commit:
=================
Manually entered input will be preserved when switching between send options on the receipt screen.

Task-4038000

This update renames an internal tour setting so that tooltip placement is easier for developers to understand and maintain. It does not change business workflows or user-facing features, but helps reduce confusion when updating guided tours across multiple apps.

In order to clarify and simplify the tours API, it was decided to rename
position to tooltipPosition. Indeed, the position key can be confusing
while the name tooltipPosition makes things very clear.

task~3974087

https://github.com/odoo/odoo/pull/174548

Current behaviour: --- Connected as Marc Demo, cannot set the Unique Field of any marketing campaign Steps to reproduce: --- 1. Go to Settings > Users > Marc Demo 2. At Marketing Automation, set User 3. Connect as Marc Demo 4. Go to Marketing Automation 5. Open any campaign 6. Try to set the Unique Field 7. Access Error Cause of the issue: --- unique_field_id is comodel of ir.model.fields Fix: --- Give group_marketing_automation_user the right to read ir.model.fields op

Current behaviour:
---
Connected as Marc Demo, cannot set the Unique Field of any marketing campaign

Steps to reproduce:
---
1. Go to Settings > Users > Marc Demo
2. At Marketing Automation, set User
3. Connect as Marc Demo
4. Go to Marketing Automation
5. Open any campaign
6. Try to set the Unique Field
7. Access Error

Cause of the issue:
---
unique_field_id is comodel of ir.model.fields

Fix:
---
Give group_marketing_automation_user the right to read ir.model.fields

opw-4001919

Forward-Port-Of: odoo/enterprise#66690

eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we try a different way to match the url, and fallback on another eBay call to get the expected variant. opw-3934127 Forward-Port-Of: odoo/enterprise#66924

eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we try a different way to match the url, and fallback on another eBay call to get the expected variant.

opw-3934127

Forward-Port-Of: odoo/enterprise#66924

Before, in a multi company and mutli website setup, booking an appointment used the companies on the organizer for the context. This was leading to issue for appointment type in Website 2 tied to Company 2. Indeed the mails for the booking were sent with the context of Company 1 (value based on the allowed_company_ids of the user). Now, when website_appointment is installed, if a website is linked to the actual request we use the company tied to it. This ensure that we always use the corre

Before, in a multi company and mutli website setup, booking an appointment used the companies on the
organizer for the context.
This was leading to issue for appointment type in
Website 2 tied to Company 2. Indeed the mails for the booking were sent with the context of Company 1 (value based on the allowed_company_ids of the user).

Now, when website_appointment is installed, if a website is linked to the actual request we use the company tied to it. This ensure that we always use the correct company of the website for the creation of the event.

We target 17.0 to avoid a behavior change in older stable as the multi website was officially supported for appointment type in that version. Could be backported if really necessary.

task-3977787

Forward-Port-Of: odoo/enterprise#64144

Steps to reproduce - Display the intrastat report with at least one line - Create a european company - Install intrastat - Create and post an invoice to partner from another european country - Open the intrastat report - Deactivate the "Grouped" filter in the Options - Activate the Comparison filter (with any other date) => Traceback stating that the query has syntax error Cause of the issue: Missing parentheses between the different sections of the UNION ALL statement. task-40

Steps to reproduce
  - Display the intrastat report with at least one line - Create a european company - Install intrastat - Create and post an invoice to partner from another european country - Open the intrastat report

  - Deactivate the "Grouped" filter in the Options
  - Activate the Comparison filter (with any other date) => Traceback stating that the query has syntax error

Cause of the issue:
Missing parentheses between the different sections of the UNION ALL statement.

task-4017165

Forward-Port-Of: odoo/enterprise#67302
Forward-Port-Of: odoo/enterprise#65720

Since odoo/odoo@c853c3b rpc requests doesn't block anymore the UI, so in commit odoo/enterprise@70c7a747a19 the manual rpc bus notifications were removed, thus preventing the loading indicator to show up. As we're not blocking the UI anymore, this commit simply change the "silent" rpc call to normal rpc calls so that the loading indicator shows up again. Forward-Port-Of: odoo/enterprise#67367

Since odoo/odoo@c853c3b rpc requests doesn't block anymore the UI, so in commit odoo/enterprise@70c7a747a19 the manual rpc bus notifications were removed, thus preventing the loading indicator to show up.

As we're not blocking the UI anymore, this commit simply change the "silent" rpc call to normal rpc calls so that the loading indicator shows up again.

Forward-Port-Of: odoo/enterprise#67367

Adding another report for SYSCEBNL. We need to provide a way to add an availability for children of a COA, so the reports is only available for Associations (and not for Companies). Forward-Port-Of: odoo/enterprise#62883

Adding another report for SYSCEBNL.
We need to provide a way to add an availability for children of a COA, 
so the reports is only available for Associations (and not for Companies).

Forward-Port-Of: odoo/enterprise#62883

[task-3847374](https://www.odoo.com/web#id=3847374&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form) [PR COM 160368](https://github.com/odoo/odoo/pull/160368) #### barcodes MOV _See COM branch for related commit_ I've moved the OGG and MP3 sounds to the barcodes module so that other modules using barcode scanner can use the same sound file. task-3847374 Related COM PR: https://github.com/odoo/odoo/pull/160368 Forward-Port-Of: odoo/enterprise#60548

[task-3847374](https://www.odoo.com/web#id=3847374&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form)
[PR COM 160368](https://github.com/odoo/odoo/pull/160368)

#### barcodes MOV
_See COM branch for related commit_
I've moved the OGG and MP3 sounds to the barcodes module so that other modules using barcode scanner can use the same sound file.

task-3847374
Related COM PR: https://github.com/odoo/odoo/pull/160368

Forward-Port-Of: odoo/enterprise#60548

Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest. In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create. See also https://github.com/odoo/odoo/pull/167236 Forward-Port-Of: odoo/enterprise#66

Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest.

In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create.

See also https://github.com/odoo/odoo/pull/167236

Forward-Port-Of: odoo/enterprise#66665
Forward-Port-Of: odoo/enterprise#66322

This traceback occurs when the `generate next recurring shifts` scheduled action runs with multiple planning slots of repeat types as `x_times`. To reproduce this issue:- 1) Install `planning` 2) Create two planning slots with `repeat` and repeat type as `Number of Occurrences` 3) For instance, manually run the `generate next recurring shifts` scheduled action Error:- ``` Expected singleton: planning.recurrency(1, 2) ``` When the scheduled action runs with multiple record s

This traceback occurs when the `generate next recurring shifts` scheduled action runs 
with multiple planning slots of repeat types as `x_times`.

To reproduce this issue:-

1) Install `planning`
2) Create two planning slots with `repeat` and
   repeat type as `Number of Occurrences`
3) For instance, manually run the `generate next recurring shifts` scheduled action

Error:- 
```
Expected singleton: planning.recurrency(1, 2)
```
When the scheduled action runs with multiple record sets, the `get_all_next_starts` 
method triggers with `self` containing `multiple recordsets`.

https://github.com/odoo/enterprise/blob/5db989feb90086d14d5c3c4f8c0d2233f7029f21/planning/models/planning_recurrency.py#L181

This leads to the `ensure one` traceback, 
when the `id` is fetching through `self`, where `self ` contains multiple recordsets.

https://github.com/odoo/enterprise/blob/5db989feb90086d14d5c3c4f8c0d2233f7029f21/planning/models/planning_recurrency.py#L119-L120

After applying this commit will resolve this issue.

sentry-5447858210

Forward-Port-Of: odoo/enterprise#67297
Forward-Port-Of: odoo/enterprise#63959

Runbot error: 71442 The error "Missing widget: productScanner for field of type char" is raised in community builds. This is linked to the fact that the widget is called in community but declared in enterprise. We thus move its usage to the enterprise view override. Community PR: odoo/odoo#173283 Forward-Port-Of: odoo/enterprise#66721

Runbot error: 71442

The error "Missing widget: productScanner for field of type char" is raised in community builds. This is linked to the fact that the widget is called in community but declared in enterprise. We thus move its usage to the enterprise view override.

Community PR: odoo/odoo#173283

Forward-Port-Of: odoo/enterprise#66721

After finally checking with a full-fledged accounting customer which is verified by tax lawyers and auditors these changes are needed to show the exact same result as left behind battle tested in `15.0` - `PCVIII` is a sum of `PCVIII3` + `PCVIII4` and those can be part of `PCVIII1` or `PCVIII2` This needs also be reflected in `ABII4` if the balance needs to be mirrored. Actually it should be similar presented in `ABII4`, but was not yet done. This might need some account tags to be adapted

After finally checking with a full-fledged accounting customer which is verified by tax lawyers and auditors these changes are needed to show the exact same result as left behind battle tested in `15.0`

- `PCVIII` is a sum of `PCVIII3` + `PCVIII4` and those can be part of `PCVIII1` or `PCVIII2` This needs also be reflected in `ABII4` if the balance needs to be mirrored. Actually it should be similar presented in `ABII4`, but was not yet done.

This might need some account tags to be adapted in Odoo Community `l10n_at` CoA, but let's start from here as it is secured and tested information.

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#64747

### Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. This issue also occurs with the Button URL as well. ### After this PR The Sample Values for Free Text Fields and Button Dynamic URL will now update based on the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#66892

### Before this PR

In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template.

This issue also occurs with the Button URL as well.

### After this PR

The Sample Values for Free Text Fields and Button Dynamic URL will now update based on the selected WhatsApp Template.

Task-3996935

Forward-Port-Of: odoo/enterprise#66892

Before this comit, on a production system, it could happen that 'subscription_state': initial_values.get('subscription_state', '1_draft') would return False. Older SQL constraint could prevent the creation of logs without subscription_state value. ```py 112 @api.model 113 def _create_creation_log(self, order, initial_values): 114 -> return self.create({ 115 'order_id': order.id, 116 'event_type': '0_creation',

Before this comit, on a production system, it could happen that
'subscription_state': initial_values.get('subscription_state',
'1_draft') would return False.
  
Older SQL constraint could prevent the creation of logs without
subscription_state value.
  
  ```py
  112         @api.model
  113         def _create_creation_log(self, order, initial_values):
  114  ->         return self.create({
  115                 'order_id': order.id,
  116                 'event_type': '0_creation',
  117                 'amount_signed': max(order.recurring_monthly, 0),
  118                 'recurring_monthly': max(order.recurring_monthly, 0),
  119                 'subscription_state': initial_values.get('subscription_state', '1_draft'),
  120             })
  [11:22]
  initial_values.get('subscription_state', '1_draft')  > False
  [11:23]
  In [7]: so.subscription_state
  Out[7]: False (modifié)
  [11:23]
  In [9]: so.is_subscription
  Out[9]: True
  
  In [10]: so.plan_id
  Out[10]: sale.subscription.plan(174,)
  ```
  
  The resulting SO could not be confirmed as the log creation would fail.
  
  How to reproduce:
  1) Create a quotation
  2) Cancel it
  3) Duplicate it
  4) Confirm it
  
  ```
  of22  File "/home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order_log.py", line 114, in _create_creation_log
  of22    return self.create({
  of22  File "<decorator-gen-12>", line 2, in create
  of22  File "/home/odoo/src/odoo/saas-17.2/odoo/api.py", line 420, in _model_create_multi
  of22    return create(self, [arg])
  of22  File "/home/odoo/src/odoo/saas-17.2/odoo/models.py", line 4679, in create
  of22    records = self._create(data_list)
  of22  File "/home/odoo/src/odoo/saas-17.2/odoo/models.py", line 4867, in _create
  of22    cr.execute(SQL(
  of22  File "/home/odoo/src/odoo/saas-17.2/odoo/sql_db.py", line 365, in execute
  of22    res = self._obj.execute(query, params)
  of22 psycopg2.errors.NotNullViolation: null value in column "subscription_state" of relation "sale_order_log" violates not-null constraint
  of22 DETAIL:  Failing row contains (2475879, null, 2024-07-17, 7020.00, 1, 2024-07-17 01:22:56.6721, 1, 2024-07-17 01:22:56.6721, 0_creation, 2617260, 209, 7020.00, 35, 17, null, null, null, 4230165, null, 4230165, null).
  ```

Forward-Port-Of: odoo/enterprise#67298
Forward-Port-Of: odoo/enterprise#67170

Description of the issue/feature this PR addresses: 1 - Create a quality.point and add a repair operation type in the 'picking_type_ids' field 2 - Create a repair picking Current behavior before PR: No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3 Desired behavior after PR is merged: Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user. opw-4052819 Forw

Description of the issue/feature this PR addresses:

1 - Create a quality.point and add a repair operation type in
	the 'picking_type_ids' field
2 - Create a repair picking

Current behavior before PR:
No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3

Desired behavior after PR is merged:
Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user.

opw-4052819

Forward-Port-Of: odoo/enterprise#67257

We are facing an access error when the planning user tries to access the conflict shift because we have not given the planning user access to the draft shift. Steps to reproduce: - Install the planning app - Go to planning - Create two shifts at the same time (one published and the other in draft) - Create a new planning user - Log in as the planning user - Open the published shift task-3823274 Forward-Port-Of: odoo/enterprise#67346 Forward-Port-Of: odoo/enterprise#66356

We are facing an access error when the planning user tries to access the conflict shift because we have not given the planning user access to the draft shift.

Steps to reproduce:
 - Install the planning app
 - Go to planning
 - Create two shifts at the same time (one published and the other in draft)
 - Create a new planning user
 - Log in as the planning user
 - Open the published shift

task-3823274

Forward-Port-Of: odoo/enterprise#67346
Forward-Port-Of: odoo/enterprise#66356