With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period. This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process. **task**-3908555 Forward-Port-Of: odoo/enterprise#66336 Forward-Port-Of: odoo/enterprise#64442

With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period.

This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process.

**task**-3908555

Forward-Port-Of: odoo/enterprise#66336
Forward-Port-Of: odoo/enterprise#64442

Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an att

Steps to reproduce:
-------------------

- Install 'Documents' and 'Accounting' modules
- Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal
- Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills
- Send a PDF to the Vendor bill mail alias
- Open the created bill

Issue:
------

Error in the chatter.

Cause:
------

We try to set on the document an attachment already linked to it, and because it goes through the versioning code, it will first link the new attachment to the record (who was already the case), and then link the old attachment (who is the same attachment as the new) to the document.

Solution:
---------

If trying to set the same attachment already linked to the document, we skip the versioning code.

opw-4034699

Forward-Port-Of: odoo/enterprise#66361

Belgium now asks the pro rata deduction for the VAT export. Mandatory if the business is concerned. Added new module to be able to add fields to the wizard. task-3916995 Forward-Port-Of: odoo/enterprise#66353 Forward-Port-Of: odoo/enterprise#65442

Belgium now asks the pro rata deduction for the VAT export. 
Mandatory if the business is concerned.
Added new module to be able to add fields to the wizard.

task-3916995

Forward-Port-Of: odoo/enterprise#66353
Forward-Port-Of: odoo/enterprise#65442

Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit:

Before this commit:

When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address.

Which causes double printing of the service point address on the label.
Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API.

After this commit:

Both the service_point_id and the customer's delivery address are sent to Sendcloud. Both addresses are printed on the label correctly.

opw-3977565

Forward-Port-Of: odoo/enterprise#65354

Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t

Issue:
===============
When a manufacturing order (MO) is created, the default components are 
automatically reserved and are made visible in the barcode module. However, 
even if these components are later unreserved, they will continue to be 
displayed in the barcode module.

Resolution:
================
To address this issue, we've taken the step to avoid forcefully re-reserving 
the components when a component is unreserved. This resolves the persistent 
display of components in the barcode.

Steps to Reproduce:
======================
1. Create a manufacturing order (MO) and confirm it.
2. Navigate to the barcode module within the manufacturing order.
3. By default, the components are reserved, so they are visible in the 
   barcode module.
4. Go to the form view of the MO in MRP and unreserve the components.
5. Check the barcode module again, and notice that the unreserved components 
   are still visible.

Expected Result:
==================
After implementing the solution, When we opens the MO in the barcode module 
only reserved components should be visible. When a component is unreserved, 
it should no longer be visible in the barcode module for manufacturing order.

task-3869731

Forward-Port-Of: odoo/enterprise#63368
Forward-Port-Of: odoo/enterprise#61827

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners. Related PR: https://github.com/odoo/odoo/pull/172399 opw-4042039 Forward-Port-Of: odoo/enterprise#66310

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners.

Related PR: https://github.com/odoo/odoo/pull/172399

opw-4042039

Forward-Port-Of: odoo/enterprise#66310

Forward-Port-Of: odoo/enterprise#66315

Forward-Port-Of: odoo/enterprise#66315

Added XML export options of the czech tax report. Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300 task-3127683 Forward-Port-Of: odoo/enterprise#66363 Forward-Port-Of: odoo/enterprise#61200

Added XML export options of the czech tax report.
Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300

task-3127683

Forward-Port-Of: odoo/enterprise#66363
Forward-Port-Of: odoo/enterprise#61200

Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce ================ - Enable "Product Packagings" and "Units of Measure"; - Select GS1 nomenclature as the Barcode Nomenclature; - Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349); - In the Barcode app, create a new receipt;

Issue
=====

When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity.

How to reproduce
================

- Enable "Product Packagings" and "Units of Measure";
- Select GS1 nomenclature as the Barcode Nomenclature;
- Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349);
- In the Barcode app, create a new receipt;
- Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units)

Expected Behavior
=================

Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead.

Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only.

[OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1)

Forward-Port-Of: odoo/enterprise#66244
Forward-Port-Of: odoo/enterprise#65073

Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour. Forward-Port-Of: odoo/enterprise#66226

Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related.
We only need to remove the moves linked to the company of the tour.

Forward-Port-Of: odoo/enterprise#66226

*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doe

*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports

Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record.

This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doesn't render the buttons if it is.

All other reports were adapted to use this hook now.

task-3932945

Forward-Port-Of: odoo/enterprise#65270

before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036

before this commit:
Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label.

After this commit:
If the insurance amount is sent, it is added to the shipping request and gets printed on label.

opw-3845693

Forward-Port-Of: odoo/enterprise#66036

Before this commit, the session report was displaying a useless line "Number of discount". It was useless as it was a duplicate. This commit removes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172054

Before this commit, the session report was displaying a useless line "Number of discount". It was useless as it was a duplicate. This commit removes it.

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

Forward-Port-Of: odoo/odoo#172054

Since 17.0 activity view now has a pager, which is not working at all. Actually there are two problems fixed in this commit - Frontend problem fixed in activity_controller.js - Backend problem fixed in mail_activity.py # First problem: Steps: - Install a module with activity view (`sale_management` for example) - Open activity view Let's say we have 4 records, at the loading of the view a request to `get_activity_data` with the following domain in the payload ``

Since 17.0 activity view now has a pager, which is not working at all.

Actually there are two problems fixed in this commit
    - Frontend problem fixed in activity_controller.js
    - Backend problem fixed in mail_activity.py

# First problem:

Steps:
    - Install a module with activity view (`sale_management` for example)
    - Open activity view

Let's say we have 4 records, at the loading of the view a request to
`get_activity_data` with the following domain in the payload
```json
{
   "domain": [
      ["user_id", "=", 2],
      ["activity_ids.active", "in", [true, false]]
   ]
}
```
the response contains for example
```json
{
    "activity_res_ids": [
        3,
        19,
        4,
        7
    ]
}
```
This is correct, the problem comes if we try to "refresh" the view
with the pager, by clicking in the pager's input and press enter
(without changing anything).
Normally it will be exactly the same request as the one above.
But the domain is not the same this time
```json
{
    "domain": [["user_id", "=", 2]]
}
```
Because of this `get_activity_data` returns incorrect data.

To fix this issue we have to do the same thing as here in the pager onUpdate()

https://github.com/odoo/odoo/blob/e11e3ca447fa2997b51a39cefc3457ae411ccb3c/addons/mail/static/src/views/web/activity/activity_model.js#L12

# Second problem:

When the model contains a different order than 'id' `get_activity_data`
can returns incorrect data since we don't specify `order` in `_search`

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

Forward-Port-Of: odoo/odoo#170519
Forward-Port-Of: odoo/odoo#164713

[FIX] l10n_tr: Fix migration script's execution phase This is a follow up to https://github.com/odoo/odoo/pull/167258 When we trigger the upgrade button of the package, We get an error that 'create_asset' field is null even that field has a default value The issue is not specified yet, Reaching the upgrade team to get their input changing the phase from 'post-' to 'end-' task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

[FIX] l10n_tr: Fix migration script's execution phase

This is a follow up to https://github.com/odoo/odoo/pull/167258
When we trigger the upgrade button of the package, We get an error that 'create_asset' field is null even that field has a default value
The issue is not specified yet, Reaching the upgrade team to get their input

changing the phase from 'post-' to 'end-'

task-id#3924220

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

Forward-Port-Of: odoo/odoo#172478

Steps to reproduce: - Create a serial tracked storable product. - Create a receipt picking for this product with quantity > 2. - Confirm the picking and assign serial numbers. - Click on "Detailed Operations" smart button. - Change the destination location of one or more move line. - Select some move lines with different destination location. - Click on "Put in Pack" button. Expected behavior: `stock.package.destination` wizard opens with only the selected move lines. Current behav

Steps to reproduce:
- Create a serial tracked storable product.
- Create a receipt picking for this product with quantity > 2.
- Confirm the picking and assign serial numbers.
- Click on "Detailed Operations" smart button.
- Change the destination location of one or more move line.
- Select some move lines with different destination location.
- Click on "Put in Pack" button.

Expected behavior:
`stock.package.destination` wizard opens with only the selected move lines.

Current behavior:
The wizard opens with all the move lines in the picking.

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

Forward-Port-Of: odoo/odoo#172488
Forward-Port-Of: odoo/odoo#172218

Trying to edit custom javascript: - Outside of developer mode, doesn't highlight the code - In developer mode, fails with a props validation error Steps to reproduce: - Stay in normal mode / Switch to developer mode - Go to Website > Homepage - Click on the "Site" menu - Click on "HTML / CSS Editor" - Click on "Edit HTML anyway" - In the file type dropdown (top left of the code editor right panel), select "JS" Old behavior: Code is not highlighted / CodeEditor props validation

Trying to edit custom javascript:
- Outside of developer mode, doesn't highlight the code
- In developer mode, fails with a props validation error

Steps to reproduce:
- Stay in normal mode / Switch to developer mode
- Go to Website > Homepage
- Click on the "Site" menu
- Click on "HTML / CSS Editor"
- Click on "Edit HTML anyway"
- In the file type dropdown (top left of the code editor right panel),
  select "JS"

Old behavior: Code is not highlighted / CodeEditor props validation
error (invalid mode)
New behavior: Code is properly highlighted, no error

This issue is happening since commit [1] because the ace CodeEditor
mode "js" was renamed to "javascript".

This commit fixes this by mapping the `ResourceEditor` type `js` to the
`CodeEditor` mode `javascript`.

This commit adds a class to the CodeEditor component usable by tests to
detect when the ace editor has changed mode.

[1]: 3e6a6d34702b2145ff998abcdf0a60ff9fbcd873

opw-3963421

Forward-Port-Of: odoo/odoo#169413

Reproduce the issue: - have an employee with one accrual allocation valid today - the allocation ends at a certain date - on his dashboard with the date picker, select a date after the allocation end - the date picker disappears Expected behaviour: - The date picker should stay on the view task-3984127 Forward-Port-Of: odoo/odoo#171993 Forward-Port-Of: odoo/odoo#169021

Reproduce the issue:
- have an employee with one accrual allocation valid today
- the allocation ends at a certain date
- on his dashboard with the date picker, select a date after the allocation end
- the date picker disappears

Expected behaviour:
- The date picker should stay on the view

task-3984127

Forward-Port-Of: odoo/odoo#171993
Forward-Port-Of: odoo/odoo#169021

Steps to reproduce: ------------------- - Install `Project` and `Field Service Reports` modules (for testing purpose) - Go to `Project` and select `Field Service` project - Open `Boiler Maintenance` task - Add some Timesheets (ensure `Hours spent` is set) and save - Click on `Sign Report` - Scroll to ensure that the `Communication History` is in the middle of the page but still can click on `Sign` button - Click on Sign Issue: ------ The message section is on top of the Sign pop

Steps to reproduce:
-------------------

- Install `Project` and `Field Service Reports` modules (for testing purpose)
- Go to `Project` and select `Field Service` project
- Open `Boiler Maintenance` task
- Add some Timesheets (ensure `Hours spent` is set) and save
- Click on `Sign Report`
- Scroll to ensure that the `Communication History` is in the middle of the page but still can click on `Sign` button
- Click on Sign

Issue:
------

The message section is on top of the Sign pop-up.
Same issue with attachment if we post a comment with attachment.

Cause:
------

There is a conflict with the `Stacking Context` of the modal, added
inside the portal sidebar who have `position:sticky`, and the message
section, that is inside a seperate div (the portal content) who have
`position:relative`.

Solution:
---------

Add a `z-index` to the sticky sidebar.

Fore more info:
https://web.dev/learn/css/z-index#stacking_context
https://talk.tiddlywiki.org/t/minimal-css-a-fix-for-dropdown-popup-hidden-by-position-sticky-title/9338

opw-3917549

Forward-Port-Of: odoo/odoo#170077

An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example) link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113 To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise a

An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example)

link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113

To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise an error as send notification.

Sentry - 5466498742

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

Forward-Port-Of: odoo/odoo#171764

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long. opw-4029891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171774

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long.

opw-4029891

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

Forward-Port-Of: odoo/odoo#171774

When customer pay using viva wallet, a traceback will appear. First, the method was called from the public controller at line [1]. From the public controller, the method from model was called at [2], where access right was checked by the code. But since the method was called from the controller, we do not have any users in the environment, so the below error will occur. Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5851, in

When customer pay using viva wallet, a traceback will appear.

First, the method was called from the public controller at line [1].
From the public controller, the method from model was called at [2],
where access right was checked by the code.
But since the method was called from the controller,
we do not have any users in the environment,
so the below error will occur.

Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.users()
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1966, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/pos_viva_wallet/controllers/main.py", line 24, in notification
    payment_method_sudo._retrieve_session_id(data_webhook)
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 115, in _retrieve_session_id
    data = self._call_viva_wallet(endpoint, 'get')
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 99, in _call_viva_wallet
    session.headers.update(self._bearer_token(session))
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 58, in _bearer_token
    if not self.env.user.has_group('point_of_sale.group_pos_user'):
  File "odoo/addons/base/models/res_users.py", line 1120, in has_group
    self.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

[1] https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/controllers/main.py#L24

[2]- https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/models/pos_payment_method.py#L58-L59

sentry-5563172568

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

Forward-Port-Of: odoo/odoo#171874

Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore. Also improve the prefetching for all messages being unlinked at the same time if related to different moves. Forward-Port-Of: odoo/odoo#172228

Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore.

Also improve the prefetching for all messages being unlinked at the same time if related to different moves.

Forward-Port-Of: odoo/odoo#172228

This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move. Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and

This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move.

Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and stock moves.

| Scenario | Before Optimization (seconds) | After Optimization (seconds) |
|----------|------------------------------|-----------------------------|
| 100 orders, 1,000 stock moves | 20 | 5 |
| 300 orders, 100,000 stock moves | 617 | 23 |

opw-3980597

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

Forward-Port-Of: odoo/odoo#171955
Forward-Port-Of: odoo/odoo#168963

Added tax report, taxes, tax groups, fiscal positions, and translated accounts. The czech l10n package was not properly setup. The tax report was missing, and wrong taxes and tax groups were used. Moreover, COA was added in czech only. task-3127683 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172506 Forward-Port-Of: odoo/odoo#158828

Added tax report, taxes, tax groups, fiscal positions, and translated accounts.

The czech l10n package was not properly setup. The tax report was missing, and wrong taxes and tax groups were used.
Moreover, COA was added in czech only.

task-3127683

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

Forward-Port-Of: odoo/odoo#172506
Forward-Port-Of: odoo/odoo#158828

Before this commit, after searching for an article via the search button, selecting it, and completing payment, the search term persisted in the search field when starting a new order. This behavior could lead to confusion or slower workflows for cashiers. opw-4015200 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172282 Forward-Port-Of: odoo/odoo#171796

Before this commit, after searching for an article via the search button, selecting it, and completing payment, the search term persisted in the search field when starting a new order. This behavior could lead to confusion or slower workflows for cashiers.

opw-4015200

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

Forward-Port-Of: odoo/odoo#172282
Forward-Port-Of: odoo/odoo#171796

Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#172404 Forward-Port-Of: odoo/odoo#168312

Create an analytic plan [TEST] with default optional availability 
Add an applicability line with:
- Domain: Expense
- Product Category: [CATEG]
- Applicability: Mandatory 

Create an expense with an expense product having categoy [CATEG]
Create Report, submit and approve

Issue: No message is raised, the action should have been blocked by the mandatory applicability

opw-3955683

Forward-Port-Of: odoo/odoo#172404
Forward-Port-Of: odoo/odoo#168312

Uninstall l10n_ar_withholding Install again l10n_ar_withholding Issue: Reinstall will fail with error odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base. This occurs because the system attempt to create a tax repartition line in existing tax instead of updating the data opw-3946193 Forward-Port-Of: odoo/odoo#172093

Uninstall l10n_ar_withholding
Install again l10n_ar_withholding

Issue:
 Reinstall will fail with error
 odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base.

This occurs because the system attempt to create a tax repartition line in
existing tax instead of updating the data

opw-3946193

Forward-Port-Of: odoo/odoo#172093

Before this commit, the error service attempted to adapt the `error.stack` format to match the one used by Chrome. But even then, the error_service_tests (that compare exactly the traceback) didn't pass on Firefox. Since version 125, even Chrome itself doesn't pass that test. This commit adapts the stack formatting code to ensure the actual error name is present and its message, but without trying to match a (too) specific format. Also in this commit, the related tests are adapte

Before this commit, the error service attempted to adapt the
`error.stack` format to match the one used by Chrome.

But even then, the error_service_tests (that compare exactly the
traceback) didn't pass on Firefox.

Since version 125, even Chrome itself doesn't pass that test.

This commit adapts the stack formatting code to ensure the actual
error name is present and its message, but without trying to match a
(too) specific format.

Also in this commit, the related tests are adapted to be a little less
strict (and more resilient), but stil ensuring the actual error name and
message are present.


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

Forward-Port-Of: odoo/odoo#172508
Forward-Port-Of: odoo/odoo#172230

This commit adds a check to prevent errors when a reward product is archived. opw-4012282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172484 Forward-Port-Of: odoo/odoo#171175

This commit adds a check to prevent errors when a reward product is archived.

opw-4012282

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

Forward-Port-Of: odoo/odoo#172484
Forward-Port-Of: odoo/odoo#171175

## Issue: Due to having 'text-bg-secondary' in our Add to Calendar button, if we modify the secondary button style for the website theme, the new style for the secondary button will not be applied properly even though it's a secondary button. ## Steps to reproduce: 1. Install website_event. 2. Modify the secondary button style for the theme (i.e set it to outline) 3. Check the button inside events > register an event. ## Solution: We could get rid of the class 'text-bg-secondary' for

## Issue:
Due to having 'text-bg-secondary' in our Add to Calendar button, if we modify the secondary button style for the website theme, the new style for the secondary button will not be applied properly even though it's a secondary button.

## Steps to reproduce:
1. Install website_event.
2. Modify the secondary button style for the theme (i.e set it to outline)
3. Check the button inside events > register an event.

## Solution:
We could get rid of the class 'text-bg-secondary' for this button which will make the button to keep same style and still be "responsive" to theme changes.

opw-3869252

Forward-Port-Of: odoo/odoo#161864

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners. Enterprise PR: https://github.com/odoo/enterprise/pull/66310 opw-4042039 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172399

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners.

Enterprise PR: https://github.com/odoo/enterprise/pull/66310

opw-4042039

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

Forward-Port-Of: odoo/odoo#172399

Before this commit, searching for paid orders using the system's date format was not possible due to the lack of proper date parsing and formatting in the search fields. opw-4008489 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171733

Before this commit, searching for paid orders using the system's date format was not possible due to the lack of proper date parsing and formatting in the search fields.

opw-4008489

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

Forward-Port-Of: odoo/odoo#171733

Steps to reproduce: - Create an account journal. - Rename the created journal (let's say from A to B). - Create a new account journal named A. Changing the name of a journal doesn't change the name of the alias, An error caused by duplicate mail alias names will occur. Additionally the error can happen if the user has manually added aliases with the same name before upgrading to 17.0. Adding the code and company id of the journal to the alias to ensure uniqueness when an alias with the

Steps to reproduce:
- Create an account journal.
- Rename the created journal (let's say from A to B).
- Create a new account journal named A.

Changing the name of a journal doesn't change the name of the alias, An error caused by duplicate mail alias names will occur. Additionally the error can happen if the user has manually added aliases with the same name before upgrading to 17.0.

Adding the code and company id of the journal to the alias to ensure uniqueness when an alias with the same name is already in the DB (as the combo `company_id`,`code` is unique).

Other possible fixes: (I'm not sure what's better here)

- Automatically rename an alias when its journal is renamed (only when they are identical after being sanitized)
- Add numbers as suffix to alias names

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

Description of the issue/feature this PR addresses: Transactions which are "locked" should not be edited through the UI Current behavior before PR: Locking a picking allowed you to change details via the smart button Desired behavior after PR is merged: Locked down more. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172041

Description of the issue/feature this PR addresses:

Transactions which are "locked" should not be edited through the UI

Current behavior before PR:

Locking a picking allowed you to change details via the smart button

Desired behavior after PR is merged:

Locked down more.



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

Forward-Port-Of: odoo/odoo#172041

stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. Zeep github issue: mvantellingen/python-zeep#140 opw-3980718 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#172080 Forward-Por

stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly.
Zeep github issue: mvantellingen/python-zeep#140

opw-3980718

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#172080
Forward-Port-Of: odoo/odoo#171722

Description of the issue/feature this PR addresses: Current behavior before PR: - In the onboarding tour, a step guides users in creating sub-tasks. Desired behavior after PR is merged: - Launch the sub-task steps only when the tour is automatically started. task-3990244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169796

Description of the issue/feature this PR addresses:

Current behavior before PR:
- In the onboarding tour, a step guides users in creating sub-tasks.

Desired behavior after PR is merged:
- Launch the sub-task steps only when the tour is automatically started.

task-3990244

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

Forward-Port-Of: odoo/odoo#169796