The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it. This commit fixes this issue by adding more freedom to these mega

The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it.

This commit fixes this issue by adding more freedom to these mega menu templates at the problematic breakpoints, so they can be more responsive with their content, while still looking good.

Step to reproduce:
- In the menu editor, add a mega menu.
- In edit mode, click on the mega menu.
- Select the "Images Subtitles" or the "Thumbnails" template.
- As a first element, write the following title: "Foto- und Fine Art Großformatdrucker".
- Save and resize down the screen until it toggles the mobile view.
- Open the mega menu and continue to resize down. => At some point, near the "SM" breakpoint, you will notice that the text becomes too big and overlaps the right element.

opw-4096112

Forward-Port-Of: odoo/odoo#177103

Method was refactored in master to get more consistent results. Stable can just get a temporary extra query. runbot-70182 Forward-Port-Of: odoo/odoo#177580

Method was refactored in master to get more consistent results. Stable can just get a temporary extra query.

runbot-70182

Forward-Port-Of: odoo/odoo#177580

Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable. This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong comp

Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable.

  This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong computation of the onchange result.

This commit send the values from parent readonly fields that have been modified (and with this align with server-side implementation behavior from `odoo.tests.form.Form`)

opw-3941571

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

Forward-Port-Of: odoo/odoo#177399

Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175605 Forward-Port-Of: odoo/odoo#171616

Adding a condition in _get_stock_account_property_field_names to avoid
recomputing the property_stock_account_production_cost_id value.

task-id: 3646156
enterprise: https://github.com/odoo/enterprise/pull/65904/

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

Forward-Port-Of: odoo/odoo#175605
Forward-Port-Of: odoo/odoo#171616

Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177332

Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover

See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992

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

Forward-Port-Of: odoo/odoo#177332

Add text editor write mode aliases. Forward-Port-Of: odoo/odoo#176974

Add text editor write mode aliases.

Forward-Port-Of: odoo/odoo#176974

From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory. However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the fi

From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory.

However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the file goes up to the limit for the format of 1048576 rows:

    $ python -c 'import openpyxl; w = openpyxl.load_workbook("odoo/addons/base/static/xls/res_partner.xlsx", data_only=True, read_only=True); print(sum(1 for _ in w.worksheets[0]))'
    1048576

even though the file only has 4 rows (including the header).

This means any client which uses this file as basis to create their own export (or a method generating similarly odd / corrupted files) requires parsing on the order of 20~30 million cells to try and import the file, even though in reality they might only have a few dozens or hundreds.

As a result the import *attempt* takes several minutes (4~5 locally, maybe a bit less on beefy server) and ~1.7GB memory, and thus routinely fails if the worker has any sort of existing pressure (e.g. well filled caches) as it hits the hard memory limit (2.5G by default).

Using the "less efficient" standard mode, the ingestion takes ~1.4s and 14.5MB memory. Which is still a far cry less efficient than xlrd.xlsx was (~0.00 seconds and 120k) but at least somewhat reasonable...

The issue has been reported upstream at https://foss.heptapod.net/openpyxl/openpyxl/-/issues/2221

Forward-Port-Of: odoo/odoo#177586

When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page. This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow. opw-4050389 Forward-Port-Of: odoo/odoo#177436 Forward-Port-Of: odoo/odoo#177207

When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page.

This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow.

opw-4050389

Forward-Port-Of: odoo/odoo#177436
Forward-Port-Of: odoo/odoo#177207

Currently, when a user has a limited access to timesheets, it is possible that he has access to a task, but that he has no access to the timesheets of its children task. This make a strange use case where the user clicks on the link to be redirected to a page without any timesheet. This fix aims to change that. Solution : change the link to the timesheets into a span if none of the timesheets are accessible by the current user. task - 3978484 version saas-17.2 Description of the iss

Currently, when a user has a limited access to timesheets, it is possible that he has access to a task, but that he has no access to the timesheets of its children task. This make a strange use case where the user clicks on the link to be redirected to a page without any timesheet.
This fix aims to change that.

Solution : change the link to the timesheets into a span if none of the timesheets are accessible by the current user.

task - 3978484

version saas-17.2

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

Issue --> Traceback appears after a user leaves a discuss channel of type `chat` or `whatsapp`. Cause --> `action_unfollow` unlinks the channel member from the `discuss.channel.member` table. When handling new message notification to show "_ has left the channel", method `channel_fetched` attempts to execute a query with an empty `discuss.channel.member` record, which raises a Postgres type mismatch error (`integer` vs ` boolean`) when setting `fetched_message_id`. Solution --> C

Issue -->

Traceback appears after a user leaves a discuss channel of type `chat` or `whatsapp`.

Cause -->

`action_unfollow` unlinks the channel member from the `discuss.channel.member` table. When handling new message notification to show "_ has left the channel", method `channel_fetched` attempts to execute a query with an empty `discuss.channel.member` record, which raises a Postgres type mismatch error (`integer` vs ` boolean`) when setting
`fetched_message_id`.

Solution -->

Check if the channel member exists, if not, then exit the method `channel_fetched`.

opw-4069813

Forward-Port-Of: odoo/odoo#177309

Problem --------- With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem: when reversing an invoice, the current company is used as recipient bank and not the customer's one. However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that. When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank. opw-4035448 --- I

Problem
---------
With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem:

when reversing an invoice, the current company is used as recipient bank and not the customer's one.

However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that.

When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank.

opw-4035448

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

Forward-Port-Of: odoo/odoo#177023

Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-

Currently, receipts are not take into account when generating the VAT Record books

### Steps to reproduce

* install `l10n_es_reports`
* switch to a Spanish company
* enable sales (or purchase) receipts in the settings
* create and confirm a sales receipt
* open the generic tax report
* select the dates for the receipt.
* attempt to generate the VAT Record books

You will be met with a traceback.

### Fix

Include receipts and treat them as invoices. (confirmed with JCO)

opw-4053187


Enterprise PR: odoo/enterprise#67621

Forward-Port-Of: odoo/odoo#175002

Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS. Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future. Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053 Forward

Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS.

Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future.


Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053

Forward-Port-Of: odoo/odoo#176651

Set up email alias for Vendor Bill journal Send email with xls attachment to alias Bill is created Issue: No attachment is present This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c the system will not add binary attachments to the created bill The change was meant to filter out rogue images often present in emails but it is too restrictive so this commit add a second check with the mimetype of the parsed attachment in order to keep u

Set up email alias for Vendor Bill journal
Send email with xls attachment to alias
Bill is created
Issue: No attachment is present

This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c
the system will not add binary attachments to the created bill
The change was meant to filter out rogue images often present in emails
but it is too restrictive so this commit add a second check with
the mimetype of the parsed attachment in order to keep useful
attachments

opw-4092311

Forward-Port-Of: odoo/odoo#176004

This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs: **Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+. **Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards. **Fixes:** - This PR fixes Bug 2 in version 15.0, ensuring the correct

This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs:

**Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+.
**Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards.

**Fixes:**

- This PR fixes Bug 2 in version 15.0, ensuring the correct amount is selected and donated.
- During the forward-port to version 17.0, we will also address Bug 1. The fix in version 17.0 will involve changes to the `payment_form.js` file, as the relevant file is no longer in use. The new solution will be cleaner and will not rely on `.o_wpayment_fee_impact`.

task-4115678

Forward-Port-Of: odoo/odoo#177270
Forward-Port-Of: odoo/odoo#176722

The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user. This results in a situation in which the user initiating the question Before this commit: It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some valu

The aim of this commit is to ensure we always have a company from which to pull values.

Context:
On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user.
This results in a situation in which the user initiating the question

Before this commit:
It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some values like `tax_calculation_rounding_method`.
For odoo.com, it resulted in a 0.01€ discrepancie between the sale order and its invoice. As the payment transaction was made based on the sale order amount, the invoice remained unpaid forcing the accountants to manually write off the difference.

After this commit:
There is always a default company provided ensuring taxes gets computed correctly and thus having sale order and invoice having the same amount.

Special thanks to PMO for his HUGE help debugging this madness.

task-id: None (issue spotted on odoo.com)

Forward-Port-Of: odoo/odoo#177618

Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points: - bus service to worker to start it - bus service to worker to initialize it - worker to bus service to acknowledge the initialization - bus service to worker to add the channel The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. Thi

Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points:
- bus service to worker to start it
- bus service to worker to initialize it
- worker to bus service to acknowledge the initialization
- bus service to worker to add the channel

The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. This PR increases the delay to ensure the flow can complete within the given time.

runbot-75076

Forward-Port-Of: odoo/odoo#177530

**Steps to reproduce:** - Create an empty db - Go to the configuration of the company - Set the country of the company to Bangladesh - Install Accounting **1st issue:** The localization module (i.e. l10n_bd) has not been installed. [Same issue with: l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug] - Go to Accounting settings - Select "

**Steps to reproduce:**
- Create an empty db
- Go to the configuration of the company
- Set the country of the company to Bangladesh
- Install Accounting

**1st issue:**
The localization module (i.e. l10n_bd) has not been installed.
[Same issue with:
l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug]

- Go to Accounting settings
- Select "Bangladesh" as Fiscal Localization
- Save the settings

**2nd issue:**
A KeyError is raised:
File "/home/odoo/src/17_1/odoo/odoo/fields.py", line 1362, in compute_value
    fields = records.pool.field_computed[self]
KeyError: 'account.asset.currency_id'

**Cause:**
**1st issue:**
"auto_install" is not present in the manifest file.

**2nd issue:**
When loading the chart template in "_load" method, "pool" attribute of "company" and "self" is not the same after the creation of a new registry. And [company = company.with_env(self.env)] does not update company.pool Therefore, when executing [self._pre_reload_data(company, template_data, data)], "self" and "company" are not on the same registry.

**Solution:**
**1st issue:**
Add 'auto_install': ['account'] in the manifest as it is done in others localization modules.

**2nd issue:**
Browse the company instead of using "with_env(self.env)" to update "company.pool".

opw-4119423




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

Forward-Port-Of: odoo/odoo#177254

Updates the tax label and description translations in order to better fit the market. Task id # 4069669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176258

Updates the tax label and description translations in order to better fit the market.

Task id # 4069669

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

Forward-Port-Of: odoo/odoo#176258

## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues. This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config: ``` _computeDataContext() { ... const data = toRaw(this.data); for (const fieldName in data) { const value = data

## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
        const data = toRaw(this.data);
        for (const fieldName in data) {
            const value = data[fieldName];
            const field = this.fields[fieldName]; // field == undefined
            if (field.relatedPropertyField) { // traceback
                continue;
            }
...
}
```

## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan, 
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error

## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.

 ## References
opw-4103712


--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#68497

Added an extra trigger, that will check that the page has properly changed from one company to another, and to let this page to load before finishing the tour. Forward-Port-Of: odoo/enterprise#68596

Added an extra trigger, that will check that the page has properly
changed from one company to another, and to let this page to load
before finishing the tour.

Forward-Port-Of: odoo/enterprise#68596

If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket). Forward-Port-Of: odoo/enterprise#68719

If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket).

Forward-Port-Of: odoo/enterprise#68719

Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#67915 Forward-Port-Of: odoo/enterprise#65904

Part of a UI task.

Changed CONTINUE/PAUSE to CONTINUE/START
Regenerated the PDF file

task-id: 3646156
community: https://github.com/odoo/odoo/pull/171616

Forward-Port-Of: odoo/enterprise#67915
Forward-Port-Of: odoo/enterprise#65904

Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-

Currently, receipts are not take into account when generating the VAT Record books

### Steps to reproduce

* install `l10n_es_reports`
* switch to a Spanish company
* enable sales (or purchase) receipts in the settings
* create and confirm a sales receipt
* open the generic tax report
* select the dates for the receipt.
* attempt to generate the VAT Record books

You will be met with a traceback.

### Fix

Include receipts and treat them as invoices. (confirmed with JCO)

opw-4053187

Comunity PR: odoo/odoo#175002

Forward-Port-Of: odoo/enterprise#67621

**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into a

**Steps to reproduce:**
- Install Accounting and l10n_co
- Switch to a Colombian company (e.g. CO Company)
- Create a bill with a line having an IVA tax and a withholding tax:
  * IVA Compra 19%
  * RteIVA 15% sobre el 19% IVA
- Post the bill
- Create another bill with a line having only an IVA tax
- Post the bill
- Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA"

**Issue:**
"Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report.

**Cause:**
The report is checking the tax lines where the account is "2408%%" to compute the amount of this column.
So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax.

**Solution:**
Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex.
It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line.
Recomputing all from the invoice lines would bad for the performance.

As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding:

[Monto del Pago Sujeto Retención = Retenido Consignado / 15%]

opw-3989661

Forward-Port-Of: odoo/enterprise#68724
Forward-Port-Of: odoo/enterprise#68016

Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner st

Accounting > Configuration > Followup Levels
Open the first level, enable 'Auto Execute'
Delete the remaining follow up levels
Create an invoice for a partner dated in the past with payment terms
'Immediate Payment'
Run manually the cron 'Account Report Followup; Execute followup'

Issue: partner will be processed by the cron, a warning will be logged
but the partner next remainder date has not changed, so the next day the
partner will be processed again.
It is an issue when partner starts to accumulate as all the partner
with missing info will be processed daily without further notice

This commit introduce the following mitigations for the issue:
- Update the next remainder date even if no message has been sent
- Limit the number of partner we process per run to 1000
- Add a message to the partner record in case the followup action failed

opw-3935084

Forward-Port-Of: odoo/enterprise#68615
Forward-Port-Of: odoo/enterprise#66770

Add a new module that supports printing to the Philippine check format Task id # 3576570 Forward-Port-Of: odoo/enterprise#56117

Add a new module that supports printing to
the Philippine check format

Task id # 3576570

Forward-Port-Of: odoo/enterprise#56117

This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#68495 Forward-Port-Of: odoo/enterprise#64260

This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt
 pour Compensation taxe Carbone" to the Luxembourg loca.

Task: 3970107

Forward-Port-Of: odoo/enterprise#68495
Forward-Port-Of: odoo/enterprise#64260