Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten

Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version.

This also correct two errors that were used in the generic SAF-T module:
- The accounts codes should be used for AccountID instead of the account database ids
- The ValueDate should be the accounting date and not the invoice date.

Based on the info from:
- Previous version SAF-T description: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-desember-2020/norwegian-saf-t-financial-data---technical-description.pdf
- New version: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-mars-2024/norwegian-saf-t-financial-data---technical-description.pdf

task-3975794

Forward-Port-Of: odoo/enterprise#71628
Forward-Port-Of: odoo/enterprise#65221

Steps to reproduce: - Switch to 'FR company' > New employee > New contract (Use defaults) - Payroll app > Payslips > All Payslips - New Payslip for your employee using a french structure (like 'cadre') - Compute sheet > Salary computation tab - (Maybe set 'Salary Journal' in Configuration > Structures if needed) Salary rule codes were translated leading to confusion in the fields to fetch when computing payroll sheets. opw-4240326 Forward-Port-Of: odoo/enterprise#72872

Steps to reproduce:
- Switch to 'FR company' > New employee > New contract (Use defaults)
- Payroll app > Payslips > All Payslips
- New Payslip for your employee using a french structure (like 'cadre')
- Compute sheet > Salary computation tab
- (Maybe set 'Salary Journal' in Configuration > Structures if needed)

Salary rule codes were translated leading to confusion in the fields to fetch when computing payroll sheets.

opw-4240326

Forward-Port-Of: odoo/enterprise#72872

Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator. Forward-Port-Of: odoo/enterprise#72799

Purpose
=======

If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator.

Forward-Port-Of: odoo/enterprise#72799

Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some workin

Steps
-----
- Install timesheet_grid
- Set monday as the first day of the week in the language settings
- Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10
- Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day.

Cause
-----
`get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some working hours near the start/end of the period to be missed.

opw-4163183

Forward-Port-Of: odoo/enterprise#72526

**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#70195

**Version:**
- 17.0

**Current Behaviour:**
- Whenever tags were added to the document, the saved notification would appear, which looked odd.
- Adding multiple tags caused the field size to increase, which was inappropriate.

**Updated Behaviour:**
- The saved notification will only appear when exiting the document. 
-  A CSS class has been added to maintain a fixed size when adding multiple tags.


task-4164151

Forward-Port-Of: odoo/enterprise#70195

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of l

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of lines that are shown.

When this limit is reached, we just don't display the exceeding lines, and replace them by a summary line.

To avoid confusion, a warning is now shown on top of the report when some lines need to be hidden. Since such a warning requires a module update (because it's a template, and needs to exist in db), we only apply our new trimming mechanism if the warning template exists (and can hence be displayed). This way, we won't change the behavior on existing databases without being sure the user is properly notified. Plus, thanks to that, we're sure the old load_more_limit value (originally 80 by default) set on the VAT Book will have been increased to a value fitting our use case more, so we won't bother people with excessive trimming.

Original fix suggestion raised here by Adhoc: https://github.com/odoo/enterprise/pull/45936

Forward-Port-Of: odoo/enterprise#72727
Forward-Port-Of: odoo/enterprise#72096

To reproduce: 1) Activate storno accounting in the settings 2) Create a new partner 3) Create a Vendor Credit Note for that partner, post it 4) Register a full payment for the credit note 5) Open the Aged Payable report ====> The partner appears in the report, even though it has an amount of 0. It shouldn't, since there is no open amount for it. This was due to the way we checked the amount of the credit note was zero. In storno, the payable line of the refund is a negative credit inst

To reproduce:

1) Activate storno accounting in the settings
2) Create a new partner
3) Create a Vendor Credit Note for that partner, post it 4) Register a full payment for the credit note
5) Open the Aged Payable report
====> The partner appears in the report, even though it has an amount of 0. It shouldn't, since there is no open amount for it.

This was due to the way we checked the amount of the credit note was zero. In storno, the payable line of the refund is a negative credit instead of being a debit. Still, it's linked through the debit_move_id field to the partial reconcile. So, removing the debit from the debit or credit from the credit wasn't enough in that setup.

opw-4166891

Forward-Port-Of: odoo/enterprise#72642
Forward-Port-Of: odoo/enterprise#72422

To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to: - Make it a variant of the Generic BS - Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplica

To reproduce the issue:

1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to:
    - Make it a variant of the Generic BS
    - Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplicate you made in 3).
7) Unfold both levels of the Receivable line.

====> Prefix groups aren't used, while the number of move lines reaches the threshold value.

This happens because the variant is opened from the Generic BS. So, options have first been generated and kept in the session for the Generic BS. When openin the variant, it receives the previously generated options as previous_options, and restores the threshold originally defined on the Generic BS.

We don't want to restore the threshold for previous options, so we just remove that code and now always initialize it to the value contained in the apporpriate field when computing the options.

Forward-Port-Of: odoo/enterprise#72822

Steps ----- 1. Create a deduplication rule for a model with a non-stored company field (e.g. Document). Add a field to the deduplication rules. 2. Run the "Data Merge: Find Duplicate Records" scheduled action. ** ValueError: <class 'psycopg2.errors.UndefinedColumn'>: "column documents_document.company_id does not exist ** Change ----- Handle the case where the company field of the model is not stored but still accessible through its related field in another table. opw-4114062 Forward

Steps
-----
1. Create a deduplication rule for a model with a non-stored company field (e.g. Document). Add a field to the deduplication rules.
2. Run the "Data Merge: Find Duplicate Records" scheduled action. ** ValueError: <class 'psycopg2.errors.UndefinedColumn'>: "column documents_document.company_id does not exist **

Change
-----
Handle the case where the company field of the model is not stored but still accessible through its related field in another table.

opw-4114062

Forward-Port-Of: odoo/enterprise#72368
Forward-Port-Of: odoo/enterprise#68816

**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward

**Steps to reproduce:**
- Install l10n_mx_reports
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to "Accounting / Reporting / Audit Reports / Trial Balance"
- Download "COA SAT (XML)"
- Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/)

**Issue:**
The validation fails because "Sello" attribute is invalid.

**Cause:**
A wrong XSLT is used to generate the digital stamp for COA SAT (XML).

opw-4209089

Forward-Port-Of: odoo/enterprise#72882

Before this commit currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction After this commit The previous button icon should appear in the right direction Task - 3845561 Forward-Port-Of: odoo/enterprise#72674 Forward-Port-Of: odoo/enterprise#61835

Before this commit

currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction

After this commit

The previous button icon should appear in the right direction

Task - 3845561

Forward-Port-Of: odoo/enterprise#72674
Forward-Port-Of: odoo/enterprise#61835

This commit aims to fix an issue in the sanitize_communication function and move its logic to the account_batch_payment module to improve reusability and testability. The function trims the communication text after removing the '/' characters. However, if the communication text contains '/' and is truncated, the '/' could end up at the end of the string (see tests for more examples). The solution is to remove the '/' after truncating the text. Additionally, the sanitize_communication funct

This commit aims to fix an issue in the sanitize_communication function and move its logic to the account_batch_payment module to improve reusability and testability.

The function trims the communication text after removing the '/' characters. However, if the communication text contains '/' and is truncated, the '/' could end up at the end of the string (see tests for more examples). The solution is to remove the '/' after truncating the text.

Additionally, the sanitize_communication function has been moved to the account_batch_payment module, since this module is a dependency for both account_sepa and account_sepa_direct_debit, these two modules can now use it as well.

The functions sanitize_communication and _sanitize_communication have been marked as deprecated and will be removed in the master branch.

opw-4220421

Forward-Port-Of: odoo/enterprise#72493
Forward-Port-Of: odoo/enterprise#71552

Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will

Before this commit:
- Creating a GST return period with a quarterly periodicity without selecting a
quarter will raise a traceback.
- Creating a GST return period with a monthly periodicity without selecting a
month will raise a traceback.

Reason:
- While calculating the start_date and end_date of the quarterly return period: 
`period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))`
If there is no month, then int(record.month) will return 0 and The month should
be between 1 and 12, so it will raise an error.
- While calculating the start_date and end_date of the monthly return period: 
`period_start = fields.Date.context_today(self).replace(day=1, month=int(record.quarter), year=int(record.year))`
If there is no quarter, then int(record.quarter) will return 0 and The month
should be between 1 and 12, so it will raise an error.

After this commit: 
- The start_date and end_date will not be calculated if a
month or quarter is not defined for the monthly or quarterly return periods.

Traceback - https://pastebin.com/LyKUDrH5

Task-4243468

Forward-Port-Of: odoo/enterprise#71883

Steps to reproduce: 1. Go to documents on mobile 2. Click on doc thumbnail 3. The inspector open where preview should open When the preview is open, click on an arrow to see the previous or the next doc 1. The inspector opens again where the previous or next should Technical Reason: In 'documents_inspector.js' file, a condition set only open the inspector if there is only one selected element, so every time it get executed and opens the inspector. After this commit: 1. Click on a

Steps to reproduce:
1. Go to documents on mobile
2. Click on doc thumbnail
3. The inspector open where preview should open

When the preview is open, click on an arrow to see the previous or the next doc
1. The inspector opens again where the previous or next should

Technical Reason:
In 'documents_inspector.js' file, a condition set only open the inspector if there is only one selected element, so every time it get executed and opens the inspector.

After this commit:
1. Click on a doc thumbnail, the preview will open.
2. When the preview is open, click on an arrow to see the previous or the next doc will not open the inspector.

Task-3919285

Forward-Port-Of: odoo/enterprise#72677
Forward-Port-Of: odoo/enterprise#62957

Sometimes when renaming the IoT box, it would instead rename to `localhost.localdomain`. This was due to the script writing to the `/tmp` directory, which sometimes gets full and causes the `/etc/hostname` file to become empty. The fix is simply to bypass using the `/tmp` directory at all in the script. task-4210432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184843

Sometimes when renaming the IoT box, it
would instead rename to `localhost.localdomain`.
This was due to the script writing to the `/tmp`
directory, which sometimes gets full and causes
the `/etc/hostname` file to become empty.

The fix is simply to bypass using the `/tmp` directory at all in the script.

task-4210432

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

Forward-Port-Of: odoo/odoo#184843

When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs. To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost This commit fixes the issue by opening the url attachment in a new tab. And "downloading" a url does not make sense, so the download button is replaced by an open button. --- I confirm I have signed

When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs.

To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost

This commit fixes the issue by opening the url attachment in a new tab.
And "downloading" a url does not make sense, so the download button is replaced by an open button.

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

Forward-Port-Of: odoo/odoo#185550
Forward-Port-Of: odoo/odoo#184264

Same issue as https://github.com/odoo/odoo/pull/126323 but with CSV, TXT and other types of files. This basically overrides the default decoding charset of the email python module to use utf-8 by default. As mentioned in the PR above, utf-8 is a superset of the ascii encoding and this should not cause other issues. opw-4237114 opw-4245261 Forward-Port-Of: odoo/odoo#185360 Forward-Port-Of: odoo/odoo#184295

Same issue as https://github.com/odoo/odoo/pull/126323 but with CSV, TXT
and other types of files.

This basically overrides the default decoding charset of the email python
module to use utf-8 by default.  As mentioned in the PR above, utf-8 is a
superset of the ascii encoding and this should not cause other issues.

opw-4237114
opw-4245261

Forward-Port-Of: odoo/odoo#185360
Forward-Port-Of: odoo/odoo#184295

**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components. **Expected behavior:** The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price. **Steps to reproduce:** 1. Create a kit product with 2 components, bot

**Current behavior:**
Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components.

**Expected behavior:**
The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price.

**Steps to reproduce:**
1. Create a kit product with 2 components, both with qty > 1

2. Assign dropshipping to the kit

3. Create a sale order and confirm -> confirm the purchase order

4. Validate the dropship transfer, invoice the sale order and post it

5. See the 2 inaccurate journal entries, where the debit/credit respectively only total to one instance of each component's cost added together

**Cause of the issue:**
The price unit calculation didn't look at the bom line product qty, only using the price unit 1 time per component.

**Fix:**
Multiply the value by the quantity of it required on its line in the BoM.

opw-4253827

Forward-Port-Of: odoo/odoo#185247
Forward-Port-Of: odoo/odoo#183916

Before this commit, it was showing a "enable push notification" messaging menu item on iOS devices. This item was persistent and could not be removed, because iOS does not allow to enable specifically push notifcation on web apps, except if there are installed as PWA in which case they necessarily authorized push notifications based on OS app preferences. opw-4236170 Backport of https://github.com/odoo/odoo/pull/178057 Forward-Port-Of: odoo/odoo#185245

Before this commit, it was showing a "enable push notification" messaging menu item on iOS devices.

This item was persistent and could not be removed, because iOS does not allow to enable specifically push notifcation on web apps, except if there are installed as PWA in which case they necessarily authorized push notifications based on OS app preferences.

opw-4236170

Backport of https://github.com/odoo/odoo/pull/178057

Forward-Port-Of: odoo/odoo#185245

**Current behavior before PR:** Before this commit: Bus channels were not added every time when threads were opened, preventing real-time messaging in some cases. **Desired behavior after PR is merged:** Added bus channel subscription when opening threads, enabling proper channel name display and real-time messaging functionality. Task:[3899453](https://www.odoo.com/odoo/project/1519/tasks/3899453) --- I confirm I have signed the CLA and read the PR guidelines at www.odo

**Current behavior before PR:**

Before this commit:

Bus channels were not added every time when
threads were opened, preventing real-time messaging in some cases.

**Desired behavior after PR is merged:**

Added bus channel subscription when opening threads,
enabling proper channel name display and real-time messaging functionality.



Task:[3899453](https://www.odoo.com/odoo/project/1519/tasks/3899453)

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

Forward-Port-Of: odoo/odoo#174473

Steps to reproduce: - Install `website_event_sale` - Go to an event and for one ticket set maximum as 1 - Open event page and purchase a ticket, but don't complete the payment - Do the same in private navigation - Click on pay on the two page Issues: If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if the

Steps to reproduce:
- Install `website_event_sale`
- Go to an event and for one ticket set maximum as 1
- Open event page and purchase a ticket, but don't complete the payment
- Do the same in private navigation
- Click on pay on the two page

Issues:
If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if there's not enough seats. Concurrency issue is not fully solved but would require much more precise timing, and a proper solution wouldn't be stable.

opw-3772093

Forward-Port-Of: odoo/odoo#173809

Steps to reproduce: 1. Navigate to Pricelists. 2. Import a CSV or XLSX file that contains at least one product or product variant. 3. Duplicate the newly created pricelist. Issue: - When duplicating an imported pricelist, the duplicated record does not retain the product or product variant information. Cause: - If the applied_on field is not provided during the creation of the pricelist item, the default value of 3_global is applied. - As a result, when duplicating the pricelis

Steps to reproduce:
1. Navigate to Pricelists.
2. Import a CSV or XLSX file that contains at least one product or product variant.
3. Duplicate the newly created pricelist.

Issue:
- When duplicating an imported pricelist, the duplicated record does not retain
  the product or product variant information.

Cause:
- If the applied_on field is not provided during the creation of the pricelist
  item, the default value of 3_global is applied.
- As a result, when duplicating the pricelist, the product_tmpl_id and
  product_id fields are set to None.

Fix:
- When the applied_on field is missing during the creation of a new pricelist
  item, set it based on the presence of the relevant fields (such as product or
  product variant).

opw-4170242

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

Forward-Port-Of: odoo/odoo#185100

There were some cache inconsistencies when computing remaining leaves on the dashboard or in the accrual scheduled actions due to commit 7ef0ad2. The cache invalidation is necessary to avoid issues when the call to process_accrual is made twice in a row, but the cache invalidation was too broad. This commit aims at only invalidating the part of the cache that were causing issues when computing the remaining leaves. opw-4167557 opw-4167582 opw-4175815 opw-4149134 opw-4241970 Forward

There were some cache inconsistencies when computing remaining leaves on the dashboard or in the accrual scheduled actions due to commit 7ef0ad2.

The cache invalidation is necessary to avoid issues when the call to process_accrual is made twice in a row, but the cache invalidation was too broad.

This commit aims at only invalidating the part of the cache that were causing issues when computing the remaining leaves.

opw-4167557
opw-4167582
opw-4175815
opw-4149134
opw-4241970

Forward-Port-Of: odoo/odoo#180832

"Tax Receivable" account shouldn't be set as a receivable account, but as a current assets one, else it will appear in aged reports, which does not make sense. Similar to the fix already made here for "Tax Payable": https://github.com/odoo/odoo/commit/2318e671c3a5535590fe6d95949835417856dce6 Forward-Port-Of: odoo/odoo#185141

"Tax Receivable" account shouldn't be set as a receivable account, but as a current assets one, else it will appear in aged reports, which does not make sense.

Similar to the fix already made here for "Tax Payable": https://github.com/odoo/odoo/commit/2318e671c3a5535590fe6d95949835417856dce6

Forward-Port-Of: odoo/odoo#185141

Steps to reproduce ================== - Install stock,mrp,web_studio - Go to Inventory > Delivery Orders - Open WH/OUT/00001 - Open studio - On the x2many field, click on "Edit form" -> Studio switches to that view, - Click on "Edit form" again for the new lines - Exit studio - Click on the hamburger button -> The styling is broken Cause of the issue ================== When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if

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

- Install stock,mrp,web_studio
- Go to Inventory > Delivery Orders
- Open WH/OUT/00001
- Open studio
- On the x2many field, click on "Edit form" -> Studio switches to that view,
- Click on "Edit form" again for the new lines
- Exit studio
- Click on the hamburger button -> The styling is broken

Cause of the issue
==================

When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if the form contains no sheet element.

In this case, there is a sheet element, but inside a nested form.

Solution
========

Only consider sheets if they are part of the current form view.

opw-4130337

Forward-Port-Of: odoo/odoo#185504

Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted

Steps to reproduce:

- insert a pivot with more rows than columns
- write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1))
- right-click on the grand total value

=> boom

When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted to the grid.

Task: 4292134





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

Forward-Port-Of: odoo/odoo#185534

When model selection field is used in a form, its default value is always one of the available values. Because of this, if the field is required, it does not force the user to pick a value, but it provides a possibly incorrect default value. This commit makes an empty value available for selection if no default value is chosen. The behavior is also made available on custom fields, if such an empty value had been manually created, it will be replaced by this implementation. Steps to

When model selection field is used in a form, its default value is
always one of the available values. Because of this, if the field is
required, it does not force the user to pick a value, but it provides a
possibly incorrect default value.

This commit makes an empty value available for selection if no default
value is chosen.
The behavior is also made available on custom fields, if such an empty
value had been manually created, it will be replaced by this
implementation.

Steps to reproduce:
- Install website_form_project
- Add a form in a page
- Select the "Create a Task" action
- Add the "Analytic Account" field to the form
- Make the field required

=> There was no way to have no default value by default.

opw-4268164

Forward-Port-Of: odoo/odoo#184842

Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done. This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move. To alleviate that, this commit uses the `report_period` as a lower bound

Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done.

This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move.

To alleviate that, this commit uses the `report_period` as a lower bound. This greatly reduces the number of rows generated by the third `UNION ALL` without losing forecasted accuracy since the moves are not in done.

#### speedup

In a v17 database where `all_sm` returns 600 000 rows, querying the `report_stock_quantity` view goes from 20s -> 7s.


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

Forward-Port-Of: odoo/odoo#179359

As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen. opw-4085163 Forward-Port-Of: odoo/odoo#185253

As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen.

opw-4085163

Forward-Port-Of: odoo/odoo#185253

This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix. Based on Real World™️ evidence. Description of the issue/feature this PR addresses: <details> ``` odoo-1  | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property:  ! odoo-1  | Traceback (most recent call last): odoo-1  |   File "/opt/odoo/auto

This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix.

Based on Real World™️ evidence.


Description of the issue/feature this PR addresses:

<details>

```
odoo-1  | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property:  !
odoo-1  | Traceback (most recent call last):
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 100, in _sync_all_google_calendar
odoo-1  |     user.with_user(user).sudo()._sync_google_calendar(google)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 78, in _sync_google_calendar
odoo-1  |     synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[google_sync.py](https://google_sync.py/)", line 202, in _sync_google2odoo
odoo-1  |     odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
odoo-1  |   File "/opt/odoo/auto/addons/google_calendar/models/[calendar_recurrence_rule.py](https://calendar_recurrence_rule.py/)", line 86, in _write_from_google
odoo-1  |     current_parsed_rrule = self._rrule_parse(current_rrule, self.dtstart)
odoo-1  |   File "/opt/odoo/auto/addons/calendar/models/[calendar_recurrence.py](https://calendar_recurrence.py/)", line 375, in _rrule_parse
odoo-1  |     rule = rrule.rrulestr(rule_str, dtstart=date_start)
odoo-1  |   File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1730, in __call__
odoo-1  |     return self._parse_rfc(s, **kwargs)
odoo-1  |   File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1698, in _parse_rfc
odoo-1  |     raise ValueError("unsupported property: "+name)
odoo-1  | ValueError: unsupported property:
```

</details>

Current behavior before PR: Odoo stops sync of users calendars as long as they have one event with an RRULE like this.

Desired behavior after PR is merged: Odoo keeps working.




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

Forward-Port-Of: odoo/odoo#185089

Before this commit : `is_html_empty` considers empty icons as empty html. After this commit: Empty icons are considered as non empty html Note: changed the tag_re to more performant regex task-4060037 Forward-Port-Of: odoo/odoo#182642

Before this commit :
`is_html_empty` considers empty icons as empty html.

After this commit:
Empty icons are considered as non empty html

Note: changed the tag_re to more performant regex

task-4060037

Forward-Port-Of: odoo/odoo#182642

Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no allocated hours are set on a task, we have null values in database that prevent the computation of allocated_hours and remaining_hours which also messes up the project totals. The computation of remaining hours is also only supposed to occur when we have a non zero amount of allocated hours,

Steps to reproduce:
- New Project > New Task > Timesheet 10h on task
- New subtask on task > Timesheet 5h on subtask
- Reporting > Tasks Analysis

Remaining hours are computed incorrectly, when no allocated hours are
set on a task, we have null values in database that prevent the
computation of allocated_hours and remaining_hours which also messes up
the project totals. The computation of remaining hours is also only
supposed to occur when we have a non zero amount of allocated hours,
otherwise the remaining hours are always 0.

Additionally, the 'Total Hours' column is confusing for customers
as it is meant to compute the total hours spent on a task (subtasks
included) but is enabled by default when looking at the projects as a
whole which does not make sense.

For instance, with 'Task' parent of 'Subtask':
| Name     | Allocated | Hours spent | Remaining  | Total Hours |
| -------- | --------- | ----------- | ---------- | ----------- |
| Project  | 0         | 15          | -15 (-> 0) | 20          |
| Task     | 0         | 10          | -10 (-> 0) | 15          |
| Subtask  | 0         | 5           | -5  (-> 0) | 5           |

The sum of total hours on project is meaningless and confusing so it is
preferable not to have it enabled by default (Subtask is counted twice,
once in Task and once itself).

opw-4236984

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

Forward-Port-Of: odoo/odoo#184291

Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The issue is the syncing (function `_sync_invoice`) between - amount in currency (document currency; field `amount_currency`) and - balance (company currency; field `balance`). There we update the amount in currency in case the balance is changed and the amount in currency is not changed. But

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#171705

Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message. opw-4196597 Forward-Port-Of: odoo/odoo#183795 Forward-Port-Of: odoo/odoo#182979

Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message.

opw-4196597

Forward-Port-Of: odoo/odoo#183795
Forward-Port-Of: odoo/odoo#182979