A small issue in the export dialog was fixed so records are labeled with the correct prefix. This helps users avoid confusion when selecting or exporting records, with minimal impact beyond the web interface.

Little error left after a refactoring

The default Field Service project now matches newly created projects by keeping task dependencies turned off. This avoids unexpected dependency settings for teams using the standard Field Service setup.

some bug fixes for the industry_fsm, documents_project

In industry_fsm,
- added allow_task_dependencies field in demo data

In documents_project,
- fixed the access right issue on clicking 'create a task'

task-2784885

The fleet payroll data now uses one consistent category for full hybrid vehicles instead of separate hybrid labels. This reduces confusion and helps ensure Belgian fleet payroll rules apply consistently.

There shouldn't be a distinction between full hybrids.
'hybrid' and 'full_hybrid_gasoline' are replaced in this commit by a unique 'full_hybrid'.
fixes task 2629318

taskID 2753096

With this commit, we allow mutliple payments with manual check printing. Steps to reproduce: - With manual check numbering - Create +=3 vendor bills - In bills list view, select all bills and register payment - Select Checks as payment methos, and validate -> Validation Error: The following numbers are already used ... Calling the super of payment.action_post in order to call sequence.next_by_id() on all payments before checking the constraint. opw-2830586 Description of the

With this commit, we allow mutliple payments with manual
check printing.

Steps to reproduce:

- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...

Calling the super of payment.action_post in order to call
sequence.next_by_id() on all payments before checking the constraint.

opw-2830586

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#91031
Forward-Port-Of: odoo/odoo#90929

Before this commit, it was possible to click on the "Create page" button before the JS was loaded, as that button is a simple link with a href. But that link is supposed to be handled by the JS which transform the GET href link to a fake form submit to send a POST request to the `/website/add` controller. If the user clicks before the JS had the chance to handle that click and do the "transformation", the controller will reject the GET request and a raw 405 error page will be shown.

Before this commit, it was possible to click on the "Create page" button
before the JS was loaded, as that button is a simple link with a href.
But that link is supposed to be handled by the JS which transform the
GET href link to a fake form submit to send a POST request to the
`/website/add` controller.

If the user clicks before the JS had the chance to handle that click and
do the "transformation", the controller will reject the GET request and
a raw 405 error page will be shown.

Now, we wait for the JS to be fully loaded before allowing user to click
on this button.
The fix is made globally as it should be the case of every link related
to this behavior.

Note that the `/website/add` controller was changed from GET to POST
with commit [1]. It most likely forgot to adapt the button from the 404
page which was later done with [2] by using the `post_link` util class
introduced with [3] (for need of website_blog at the time).

[1]: https://github.com/odoo/odoo/commit/714f0aa07f25e8a88a778e8b21c79b48e9801231
[2]: https://github.com/odoo/odoo/commit/2c85c1cb6ee0f6000cd2db182d5b8cfd3d040876
[3]: https://github.com/odoo/odoo/commit/0f2cada32319b3910d6ace6d412cfa94a646c9c7

task-2847785

Forward-Port-Of: odoo/odoo#90869

# Description of the issue/feature this PR addresses: Cannot Start a Workorder with multiple users. # Current behavior before PR: With User1, create a MO with work orders, and start one Work Order. With User2, go to the MO, and start the same Work Order => Nothing happen, we currently prevent the workorders to have more than 1 open Time Tracking. # Desired behavior after PR is merged: Multiple Users can start the same Workorder (only 1 at a time each) OPW-2845080 --- Issue rece

# Description of the issue/feature this PR addresses:
Cannot Start a Workorder with multiple users.

# Current behavior before PR:
With User1, create a MO with work orders, and start one Work Order.
With User2, go to the MO, and start the same Work Order
=> Nothing happen, we currently prevent the workorders to have more than 1 open Time Tracking.

# Desired behavior after PR is merged:
Multiple Users can start the same Workorder (only 1 at a time each)

OPW-2845080

---
Issue recently introduced by this PR: https://github.com/odoo/odoo/pull/89627
From this ticket: https://www.odoo.com/web#id=2802436&cids=1&menu_id=4720&action=3531&model=project.task&view_type=form

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

Forward-Port-Of: odoo/odoo#91033

### Observed Behaviour When opening a pivot view (in any of Odoo module) and trying to import it in a Google Spreadsheet, we get the following error: > UncaughtPromiseError > TypeError > Uncaught Promise > Cannot read properties of undefined (reading 'id') > TypeError: Cannot read properties of undefined (reading 'id') > at AddToGoogleSpreadsheet.addToGoogleSpreadsheet (...) > at HTMLSpanElement.eval (eval at _compile (...) > ### Expected Behaviour When trying to import the pivot i

### Observed Behaviour
When opening a pivot view (in any of Odoo module) and trying to import it in a Google Spreadsheet, we get the following error:

> UncaughtPromiseError > TypeError
> Uncaught Promise > Cannot read properties of undefined (reading 'id')
> TypeError: Cannot read properties of undefined (reading 'id')
> at AddToGoogleSpreadsheet.addToGoogleSpreadsheet (...)
> at HTMLSpanElement.eval (eval at _compile (...)
> 

### Expected Behaviour
When trying to import the pivot in a spreadsheet, everything should work fine, openning a new tab with a Google spreadsheet.

### Reproducibility
This issue can be reproduced following these steps:
1. Install the 'Google Spreadsheet" module
2. Go to 'Settings' > 'Google Drive' and set your credentials
3. Go to the Sales App
4. Select the pivot view
5. Click on 'Favorites' > 'Add To Google Spreadsheet'

### Fix Description
The original issue was coming from the fact we try to access the ID of a null view, giving us the reported error. Moreover, after fixing this issue, we got another error coming from the fact the config method was called with a domain passed as a list, while it need a string. Both errors were corrected in the way it was already done in
https://github.com/odoo/odoo/blob/2e5acb4b15422c1ee38c5630e4fdb929d7a24d3c/addons/google_spreadsheet/static/src/legacy/js/add_to_google_spreadsheet_menu.js#L25

### Related Issues/PR
- opw-2794744
- opw-2761065
- opw-2752840

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

Forward-Port-Of: odoo/odoo#89967

It may happen than the routing map is cleared while rendering a qweb view. For example, if an asset bundle is regenerated, the previous one is unlinked, which causes a cache clearing. Previously-generated `EndPoint` objects aren't found any more in the new routing map, so `request.endpoint` cannot be used any more after a cache clearing. This commit adds hash and comparison magic methods on `http.EndPoint` so that `EndPoint` objects created by a previous routing map generation can still be

It may happen than the routing map is cleared while rendering a qweb view. For example, if an asset bundle is regenerated, the previous one is unlinked, which causes a cache clearing.

Previously-generated `EndPoint` objects aren't found any more in the new routing map, so `request.endpoint` cannot be used any more after a cache clearing.

This commit adds hash and comparison magic methods on `http.EndPoint` so that `EndPoint` objects created by a previous routing map generation can still be used after a cache clearing.

Two tests were added: one to test the comparison and hash methods, and the other to test them in a real-case rendering.

Commit 80a04f7ebed fixed this bug too, but introduced another issue which caused many OPW, so it was quickly reverted by deb23450f18 along with its performance improvement 33167b3928c. This commit replaces 80a04f7ebed with another way to fix the issue.

[OPW-2834546](https://www.odoo.com/web#model=project.task&id=2834546)
[OPW-2834549](https://www.odoo.com/web#model=project.task&id=2834549)
[OPW-2834625](https://www.odoo.com/web#model=project.task&id=2834625)

Forward-Port-Of: odoo/odoo#90824
Forward-Port-Of: odoo/odoo#90005

Current behavior: When gift card module is activated for a certain PoS, and you use customer account as the payment method without selecting a customer the popup asking you to select a customer would appear 2 times. Steps to reproduce: - Activate gift cards for PoS A - Start session in PoS A - Add some products to the order - Don't set any customer - Go to the payment page - Select "Customer account" as payment method - Click on validate - A popup will appear asking you to select a

Current behavior:
When gift card module is activated for a certain PoS, and you use
customer account as the payment method without selecting a customer
the popup asking you to select a customer would appear 2 times.

Steps to reproduce:
- Activate gift cards for PoS A
- Start session in PoS A
- Add some products to the order
- Don't set any customer
- Go to the payment page
- Select "Customer account" as payment method
- Click on validate
- A popup will appear asking you to select a customer
- Click "Ok"
- The popup appears again

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

Forward-Port-Of: odoo/odoo#91063
Forward-Port-Of: odoo/odoo#90857

Steps to reproduce the bug: - Install sale_stock and invoicing - Create a product tracked by serial number “P1” - Create a SO: - Select any customer - Select the product “P1” - Confirm the SO - Confirm the linked picking - Go back to the SO - Create the invoice - Post the invoice - Give “sales” and “accounting“ rights to Marc Demo - Connect with Marc - Go to the posted invoice - Try to print the invoice Problem: Traceback is triggered, to print the invoice we have to

Steps to reproduce the bug:
- Install sale_stock and invoicing
- Create a product tracked by serial number “P1”
- Create a SO:
   - Select any customer
   - Select the product “P1”
   - Confirm the SO
- Confirm the linked picking
- Go back to the SO
- Create the invoice
- Post the invoice

- Give “sales” and “accounting“ rights to Marc Demo
- Connect with Marc
- Go to the posted invoice
- Try to print the invoice

Problem:
Traceback is triggered, to print the invoice we have to access the `Lot` field
which is defined in the stock module but as the user does not have access rights
an error is triggered:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/views/report_invoice.xml#L5

opw-2832396




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

Forward-Port-Of: odoo/odoo#90779

Steps to reproduce: - Install Recruitment module - Set a valid outgoing mail server and archive it - Go to Recruitment > Applications > All Applications - Create a new application - Set a Subject and email, then save - Click on button 'Refuse' - Select any reason (ensure "send email" is checked) Issue: The email is sent to the applicant through the archived email server. Cause: The current action have 'active_test' set to 'False' in the context (useful w

Steps to reproduce:

  - Install Recruitment module
  - Set a valid outgoing mail server and archive it
  - Go to Recruitment > Applications > All Applications
  - Create a new application
  - Set a Subject and email, then save
  - Click on button 'Refuse'
  - Select any reason (ensure "send email" is checked)

Issue:

  The email is sent to the applicant through the archived email server.

Cause:

  The current action have 'active_test' set to 'False' in the context
  (useful when archiving an applicant though action menu, since it
  trigger action 'action_refuse_reason_apply' and current applicant
  will be archived at that point).
  Therefore, the archived email server will be used (in case it's the
  only one, or if it has more priority than any other one).

Solution:

  Set 'active_test' to 'True' in the context when sending mail.

opw-2845545

Forward-Port-Of: odoo/odoo#91086

Purpose Fix bugs in link replacement (html and text version) 1/ The replacement of urls in text (not html) was buggy when * a string includes multiple urls, and * `base_url` is one of them and not the first * Also in SMS marketing when adding the sms `id` When it came to base_url's turn, the replace function for the content would replace the `base_url` part of a previously shortened url instead of the distinct `base_url` link. 2/ Ampersand character A) The ampersand character pre

Purpose
Fix bugs in link replacement (html and text version)

1/ The replacement of urls in text (not html) was buggy when
* a string includes multiple urls, and
* `base_url` is one of them and not the first
* Also in SMS marketing when adding the sms `id`

When it came to base_url's turn, the replace function for the content would
replace the `base_url` part of a previously shortened url instead of the
distinct `base_url` link.

2/ Ampersand character
A) The ampersand character prevented replacement of an url inside a `Markup`.
Previous tests passed as the tracker was created but the url was not replaced.

B) The ampersand character was not recognized as part of an url for simple
strings.

3/ Replacement of already short links
A faulty logic made it possible to replace "/r/" urls when no "blacklist" was
passed.

Commit
* Ensures that only the base_url link would be replaced instead in this case.
* Adds support for urls with "&"
* Does prevent shortening short urls
* Improves link conversion performance (regex + avoid duplication when there
  are several occurrences of the same url)
* Adds multiple unit tests

Task-2783844

Forward-Port-Of: odoo/odoo#91088
Forward-Port-Of: odoo/odoo#86003

Before this commit, if the user does not follow the project then while creating the task the creator(the current user) is not added as a follower of the task. So in this commit, add the user creator of a task as a follower by default, even if (s)he is not following the project. task-2784885 Forward-Port-Of: odoo/odoo#89386

Before this commit, if the user does not follow the project then while creating the task the creator(the current user) is not added as a follower of the task.

So in this commit, add the user creator of a task as a follower by default, even if (s)he is not following the project.

task-2784885

Forward-Port-Of: odoo/odoo#89386

In a multi-company environment, a partner of company A should not be able to make payments for company B. With this commit, if we detect a mismatch between the companies, a UserError is raised. task-2627751 See also: - https://github.com/odoo/enterprise/pull/26941 Forward-Port-Of: odoo/odoo#91038 Forward-Port-Of: odoo/odoo#79683

In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.

task-2627751

See also:
- https://github.com/odoo/enterprise/pull/26941

Forward-Port-Of: odoo/odoo#91038
Forward-Port-Of: odoo/odoo#79683

Before this commit, When a user has a sale order all document right, project the user right, and try to open a sale order linked with a private project then it raises an access rights error when a user clicks on sales orders in a project, even though the user has the correct rights due to invalid access on the project_ids field. so in this commit, fixes the issue by changing the group on those fields as those fields are only used in the stat button and it will be only visible to the project m

Before this commit, When a user has a sale order all document right, project the user right, and try to open a sale order linked with a private project then it raises an access rights error when a user clicks on sales orders in a project, even though the user has the correct rights due to invalid access on the project_ids field.

so in this commit, fixes the issue by changing the group on those fields as those fields are only used in the stat button and it will be only visible to the project manager.

task-2792884

Forward-Port-Of: odoo/odoo#87632

Prior to this commit the discountable amount on specific products was not computed correctly when using fixed price discounts as it did not take the taxes into account. They will now be taken into account and result in the correct discount. TaskId-2834863 Forward-Port-Of: odoo/odoo#89892

Prior to this commit the discountable amount on specific products was
not computed correctly when using fixed price discounts as it did not
take the taxes into account.
They will now be taken into account and result in the correct discount.

TaskId-2834863

Forward-Port-Of: odoo/odoo#89892

Before this commit, the publication toggler in mobile (`.css_unpublished`) was not styled correctly and the whole button was not aligned with the menu. After this commit, the correct style and alignment are applied. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88074

Before this commit, the publication toggler in mobile
(`.css_unpublished`) was not styled correctly and the whole button was
not aligned with the menu.

After this commit, the correct style and alignment are applied.

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

Forward-Port-Of: odoo/odoo#88074

Description of the issue/feature this PR addresses: This provides the possibility to import/export simplified invoices. Current behavior before PR: Currently, the import of simplified invoices would not work and the export of invoice without customer address would be blocked. Desired behavior after PR is merged: Simplified invoice can be imported and export can be done if the customer address is incomplete, it's a domestic invoice and the total amount is below 400€ Task: 2800967 -

Description of the issue/feature this PR addresses:
This provides the possibility to import/export simplified invoices.

Current behavior before PR:
Currently, the import of simplified invoices would not work and the export of invoice without customer address would be blocked.

Desired behavior after PR is merged:
Simplified invoice can be imported and export can be done if the customer address is incomplete, it's a domestic invoice and the total amount is below 400€

Task: 2800967

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

Forward-Port-Of: odoo/odoo#90974
Forward-Port-Of: odoo/odoo#90052

How to reproduce the bug ? - install hr_payroll and web_studio - in Settings > Technical > Automated Actions, create a new action linked to the Payslip model - Go to the Payslip app and generate a payslip by choosing an employee that has work entries What is the bug ? When you create an automated action, you will overwrite the origin write function of the model. However, the origin write function will still be called by the new write function. In the new write function, the recor

How to reproduce the bug ?

- install hr_payroll and web_studio
- in Settings > Technical > Automated Actions, create a new action
linked to the Payslip model
- Go to the Payslip app and generate a payslip by choosing an employee
that has work entries

What is the bug ?

When you create an automated action, you will overwrite the origin write
function of the model. However, the origin write function will still be
called by the new write function.
In the new write function, the records will be filtered according to
their ids. This means that if a record has a NewId, it will not be
handled. This is the bug here since the payslip is under creation.

Signed-off-by: Adrien Minet <admi@odoo.com>

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

Forward-Port-Of: odoo/odoo#88071

Inserting `w.r.t` in the editor transformed it into an url. This kind of content should not be considered as an url. task-2795012 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#86515

Inserting `w.r.t` in the editor transformed it into an url.
This kind of content should not be considered as an url.

task-2795012





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

Forward-Port-Of: odoo/odoo#86515

Before this commit, whenever the element that must be deleted by `deleteBackspace` matches `isMediaElement` or `isNotEditableNode` and the cursor was in the beginning of a `<p>` with inline content, the inline content moved to the parent and the `<p>` was deleted. Which is wrong. Now, whenever the element that must be deleted by `deleteBackspace` matches `isMediaElement` or `isNotEditableNode`, no inline content moves. Task-2781328 -- I confirm I have signed the CLA and rea

Before this commit, whenever the element that must be deleted by
`deleteBackspace` matches `isMediaElement` or `isNotEditableNode` and
the cursor was in the beginning of a `<p>` with inline content, the
inline content moved to the parent and the `<p>` was deleted.
Which is wrong.

Now, whenever the element that must be deleted by `deleteBackspace`
matches `isMediaElement` or `isNotEditableNode`, no inline content
moves.

Task-2781328




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

Forward-Port-Of: odoo/odoo#86363

Before this commit, when hitting enter while not in composition mode, the editor sometimes removed all the content that was added the previous composition. task-4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#86512

Before this commit, when hitting enter while not in composition mode,
the editor sometimes removed all the content that was added the previous
composition.

task-4720




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

Forward-Port-Of: odoo/odoo#86512

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#91207 Forward-Port-Of: odoo/odoo#90575

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#91207
Forward-Port-Of: odoo/odoo#90575

The file extension detection previously used to determine whether a filename required an extension was not very smart and in fact only checked for a dot in the filename. `mimetypes.guess_type` is now used on the filename to better determine whether the filename still needs a file extension or not. This commit is a follow-up to: https://github.com/odoo/odoo/pull/90614 Which aimed to fix the same issue. TaskId-2826061 Forward-Port-Of: odoo/odoo#91227 Forward-Port-Of: odoo/odoo#90855

The file extension detection previously used to determine whether a
filename required an extension was not very smart and in fact only
checked for a dot in the filename.
`mimetypes.guess_type` is now used on the filename to better determine
whether the filename still needs a file extension or not.

This commit is a follow-up to: https://github.com/odoo/odoo/pull/90614
Which aimed to fix the same issue.

TaskId-2826061

Forward-Port-Of: odoo/odoo#91227
Forward-Port-Of: odoo/odoo#90855

before this commit, sla success filter contained tickets that had already failed. so after this commit the sla success filter will only contain success tickets. task-2784885 Forward-Port-Of: odoo/enterprise#27227 Forward-Port-Of: odoo/enterprise#25589

before this commit, sla success filter contained tickets that had already failed.

so after this commit the sla success filter will only contain success tickets.

task-2784885

Forward-Port-Of: odoo/enterprise#27227
Forward-Port-Of: odoo/enterprise#25589

Step to reproduce: - Duplicate a payslip - Try to change the `date_to` Current behaviour: - .unlink() in `_compute_worked_days_line_ids` trigger a cache invalidation which reset the 'date_to` to it's original value as it's been set in an onchange. (cf https://github.com/odoo/odoo/blob/d467881f66b11021005005584854f30059971b6c/odoo/models.py#L3707 ) Behaviour after PR: - Clearing instead of unlinking does not trigger the cache invalidation in the onchange opw-2843063 Forward-Port

Step to reproduce:
- Duplicate a payslip
- Try to change the `date_to`

Current behaviour:
- .unlink() in `_compute_worked_days_line_ids` trigger a cache
invalidation which reset the 'date_to` to it's original value
as it's been set in an onchange.
(cf https://github.com/odoo/odoo/blob/d467881f66b11021005005584854f30059971b6c/odoo/models.py#L3707 )

Behaviour after PR:
- Clearing instead of unlinking does not trigger the cache
invalidation in the onchange

opw-2843063

Forward-Port-Of: odoo/enterprise#27144

In a multi-company environment, a partner of company A shoud not be able to make payments for company B. With this commit, if we detect a mismatch between the companies, a UserError is raised. Task - 2627751 See also: - https://github.com/odoo/odoo/pull/79683 Forward-Port-Of: odoo/enterprise#27216 Forward-Port-Of: odoo/enterprise#26941

In a multi-company environment, a partner of company A shoud not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.

Task - 2627751

See also:
- https://github.com/odoo/odoo/pull/79683

Forward-Port-Of: odoo/enterprise#27216
Forward-Port-Of: odoo/enterprise#26941

Before this commit, when the user clicks on the 'create a task' button leads to an access right error due to creation of a private task without the user assigned to that task. So this commit fixes the issue by setting the current user as assignee in that private task. task-2784885 Related PR: - odoo/odoo/pull/89386 Forward-Port-Of: odoo/enterprise#25650

Before this commit, when the user clicks on the 'create a task' button leads to an access right error due to creation of a private task without the user assigned to that task.

So this commit fixes the issue by setting the current user as assignee in that private task.

task-2784885

Related PR:
- odoo/odoo/pull/89386

Forward-Port-Of: odoo/enterprise#25650

When opening the Aged Receivable reports in Safari, the elements in the table can no longer be foldable once the user started to scroll on the table. Step to reproduce the issue: 1. Open Safari 2. Install the accounting app 3. Create many (at least 20) invoices on different customers 4. Go to Accounting > Reporting > Age receivable 5. Unfold different customer so that you are forced to scroll in the page (as there are too many entries to view them all on a single page). If you are lazy

When opening the Aged Receivable reports in Safari, the elements in the table
can no longer be foldable once the user started to scroll on the table.

Step to reproduce the issue:
1. Open Safari
2. Install the accounting app
3. Create many (at least 20) invoices on different customers
4. Go to Accounting > Reporting > Age receivable
5. Unfold different customer so that you are forced to scroll in the page (as
there are too many entries to view them all on a single page). If you are lazy,
you can shrink your window size so that you are forced to scroll with less
entries.
You will see that you can no longer unfold other entries.

Solution: In order to have a scrollable (in the Y-axis) table, a trick was
done to clone the original table and keeps only the header. For some reason,
`pointer-events` are working fine in Google Chrome but not in Safari.
Consequently, the `pointer-events` CSS property has been enforced to ensure
reliability (we only allowed `pointer-events` on the header of the table).
Furthermore, another issue was present in Safari. When unfolding/folding, the
text of each row disappeared (only in Safari). Upon investigation, the issue
comes from the `position: relative` which pose issues on Safari. Consequently,
and as the property is not useful in itself (due to parent properties), we
can simply remove it to solve the issue.

opw-2830147

Forward-Port-Of: odoo/enterprise#26875

[FIX] account_reports: filtering partners on partner ledger The filter partners on account reports does not apply when exporting a report Steps to reproduce : 1. Go to Accounting -> Reporting -> Partner reports -> Partner Ledger 2. In Search partner, filter a partner 3. Print the pdf or the Excel 4. All partners are included in the report Solution : Add the partner filter to the domain Task-id: 2812382 Signed-off-by: Ruben Gomes <rugo@odoo.com> Forward-Port-Of: odoo/enterpri

[FIX] account_reports: filtering partners on partner ledger

The filter partners on account reports does not apply when exporting a report

Steps to reproduce :
1. Go to Accounting -> Reporting -> Partner reports -> Partner Ledger
2. In Search partner, filter a partner
3. Print the pdf or the Excel
4. All partners are included in the report

Solution :
Add the partner filter to the domain

Task-id: 2812382

Signed-off-by: Ruben Gomes <rugo@odoo.com>

Forward-Port-Of: odoo/enterprise#27052
Forward-Port-Of: odoo/enterprise#26375

Since the merge of odoo/odoo#87266 we can pass with_commit=False to account_move.action_process_edi_web_services() Therefore _action_process_edi_web_services is no longer useful Forward-Port-Of: odoo/enterprise#26722

Since the merge of odoo/odoo#87266 we can pass with_commit=False to
account_move.action_process_edi_web_services()
Therefore _action_process_edi_web_services is no longer useful

Forward-Port-Of: odoo/enterprise#26722

On the frontend, the account name is split into words, if the start of any of these words matches the search string, the account is considered a match. In the backend the word splitting is omitted, so only the start of the complete name can match the search string. This ambiguous behavior also leads to the impossibility to match search strings containing spaces in the frontend. This inconsistency can eventually lead to an error when trying to load the expanded view of an account that is match

On the frontend, the account name is split into words, if the start of any of these words matches the search string, the account is considered a match. In the backend the word splitting is omitted, so only the start of the complete name can match the search string. This ambiguous behavior also leads to the impossibility to match search strings containing spaces in the frontend.

This inconsistency can eventually lead to an error when trying to load the expanded view of an account that is matched in the frontend, but not in the backend. When using the search box, the displayed lines will be filtered by the `filter_accounts` method in the `accountReportsWidget`. If the end user now decides to expand one of the filtered lines, the child lines will be fetched from the server by calling `get_html` on the `account.general.ledger` model including the search string as a parameter. Because of the inconsistency between the front and back end logic it is now possible that an account matched in the frontend will not actually match the search string in the backend. When this happens, a `KeyError` occurs when the `_do_query` explicitly tries to retrieve the child lines of the expanded account.

Additionally, the filtering logic in the backend will be used when printing or exporting reports. As such, if the backend yields different results, these will be reflected in the printed or exported report.

The backend logic was probably the intended logic, while the word splitting in the frontend was probably only intended to remove the account code (which is prepended to the display name in the frontend). This can be seen from the original code included in [commit 1] and modified by [commit 2] where the backend would do a simple `ilike` match on any substring in the account name or code. This generally worked fine, because the results in the backend were always a superset of those in the frontend. However, even then, the printed report would not generally reflect the results in the frontend.

Things worsened considerably as of [commit 3], which tried to fix some of the inconsistencies between frontend and printed or exported reports. The commit is fundamentally flawed though, restricting the results in the backend far too much. The exported reports would still not match the frontend, and far more importantly, expanding any of the results from any search for a prefix of any but the first word in the account name (you'll probably have to read this a couple of times...) would now result in the traceback error described above.

The search functionality on the account reports is adapted, so that the result set matches the one returned by using `name_search`.


[commit 1]: https://github.com/odoo/enterprise/commit/575e8a4b41d1dcb7189327e723be6dc8379d07ad
[commit 2]: https://github.com/odoo/enterprise/commit/5b000eaa28e8494d2fed043d811d228383bfe704
[commit 3]: https://github.com/odoo/enterprise/commit/a6e0004b46fb2feaa2ae95834dce8a3a8738f0a8

opw-2821275
opw-2821643
opw-2822098
opw-2822231
opw-2822680
opw-2822794
opw-2823255
opw-2823349
opw-2824231
opw-2824287
opw-2824401
opw-2824526
opw-2825405

Forward-Port-Of: odoo/enterprise#27168
Forward-Port-Of: odoo/enterprise#26292