The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo. The test was failing because of the following: when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`. However the list of `event.attendee_ids` is ordered by create_date. And we create both organizer and attendee with the same command at th

The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo. The test was failing because of the following:
when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`. However the list of `event.attendee_ids` is ordered by create_date. And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]` So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test.

To fix this issue:
This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee.

fixes runbot-61527

Forward-Port-Of: odoo/odoo#161451

LATAM 1175, ADHOC Task 34189 ---- ### Description of the issue/feature this PR addresses: Clean up field value when is not going to be used: if tax type != none or we are not Argentinean tax then we clean up the value of the Argentinean Withholding type and set it to False. We want it to behave as an onchange: for that, we change the field to be a compute one stored True and continue to be editable by the user. ### Current behavior before PR: If we change the configuration of a tax

LATAM 1175, ADHOC Task 34189
----

### Description of the issue/feature this PR addresses:

Clean up field value when is not going to be used: if tax type != none or we are not Argentinean tax then we clean up the value of the Argentinean Withholding type and set it to False. We want it to behave as an onchange: for that, we change the field to be a compute one stored True and continue to be editable by the user.

### Current behavior before PR:

If we change the configuration of a tax the Argentinean Withholding type will maitain set not matter is not needed and it is not used. 

### Desired behavior after PR is merged:

If we change the tax configuration the Argentinean Withholding type field will be clean up in the needed cases

Here is a video showing an example https://drive.google.com/file/d/1yMcC-QOJQrh53l-krFDRY7K4xZxMmE8n/view



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

Forward-Port-Of: odoo/odoo#156808

## Problem Before this commit, adding a dropdown to a kanban view via `web_studio` didn't work. Steps: - Install `web_studio` - Install a module containing no dropdown on the kanban view (e.g. `sale_management`) - Modify the kanban view of this module on studio - Click on the 3 small dots on the kanban-card and add the dropdown - Confirm - Exit studio - Try changing the color of one of the kanban-cards via the newly added dropdown - Traceback ## Explanation Here's how adding a drop

## Problem
Before this commit, adding a dropdown to a kanban view via `web_studio` didn't work.
Steps:
- Install `web_studio`
- Install a module containing no dropdown on the kanban view (e.g. `sale_management`)
- Modify the kanban view of this module on studio
- Click on the 3 small dots on the kanban-card and add the dropdown
- Confirm
- Exit studio
- Try changing the color of one of the kanban-cards via the newly added dropdown
- Traceback

## Explanation
Here's how adding a dropdown to the kanban view normally works in studio:
Python:
- Create a new `x_color` field in the model
- Add this new field to the view in question
- Add a dropdown containing `.oe_kanban_colorpicker` and a `data-field` containing `x_color`.
- Change the attributes of the first element in the kanban-card to add a color="x_color".

Javascript:
If the color is changed, this code is triggered

https://github.com/odoo/odoo/blob/0fcb34dd3ba3bbd7f422c627e27c96089b29b044/addons/web/static/src/views/kanban/kanban_record.js#L302-L306

which dynamically updates the `colorpicker` field with the new value via the value of arch `colorField`.
Except that in our case `colorField` is `color` and not `x_color`.

Then, as the `web_studio` python code adds a `color="x_color"` attribute, instead of `colorField` it's `cardColorField`.

https://github.com/odoo/odoo/blob/3c356a40f7d6da5aff8a8e7f6ebb9ea8cc9b3861/addons/web/static/src/views/kanban/kanban_record.js#L266-L269

This code is obsolete because it adds `oe_kanban_color_X` to `o_kanban_record ` instead of adding it to its first child `oe_kanban_card`.

So we have several problems:
- Use of `cardColorField` instead of `colorField`.
- Color style added to wrong HTML element
- KanbanArchParser searches for the colorpicker's `data-field` only in `kanban-box`, whereas it is often (including in studio) put in `kanban-menu`.

## Commits
### Commit 1: [[FIX] web: Use kanban-menu template in arch kanban_arch_parser](https://github.com/odoo/odoo/pull/160483/commits/bb0cf9ef09ac29233b99b64077c9b31bcd4a04a0)

This commit modifies the way kanban_arch_parser retrieves `colorField`.

Previously, the parser tried to retrieve only `colorField`
(the `data-field` attribute of `.oe_kanban_colorpicker`) from `kanban-box`.
Except that in most cases `.oe_kanban_colorpicker` is defined in
`kanban-menu` and not `kanban-box`.

for example:

https://github.com/odoo/odoo/blob/31107fb4cc9cf5dc2da21cbfef58dae722c73922/addons/crm/views/crm_lead_views.xml#L554-L559
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project/views/project_task_views.xml#L544-L550
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project_todo/views/project_task_views.xml#L28-L31
etc.

As a result, this code was always ignored and we always fallback on `||"color"`.
```js
 const colorField = (colorEl && colorEl.getAttribute("data-field")) || "color";
```

Now `KanbanArchParser` checks both `kanban-box` and `kanban-menu` and
finally fallbacks to `color`.


### Commit 2: [Put kanban color classes in the right place](https://github.com/odoo/odoo/pull/160483/commits/73844cd42a389020bd4a7bd47ed48c4652fa7e4d)

After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.

The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).


A commit has also been made in the enterprise section to remove unnecessary code from the `web_studio` controller, which before this pull request was used to add a color="x_color" attribute that we no longer use.

https://github.com/odoo/enterprise/pull/60072


opw-3823860

Forward-Port-Of: odoo/odoo#161645
Forward-Port-Of: odoo/odoo#160483

**[FIX] payment(_stripe): adapt validation currency to payment method** When payment details are tokenized through a validation operation, the currency to use was usually (except overrides) chosen as that of the payment provider's company. This sometimes caused compatibility issues if the selected payment method did not support the company's main currency. For example, the SEPA Direct Debit payment method only supports the EUR currency. This commit allows passing a payment method when gett

**[FIX] payment(_stripe): adapt validation currency to payment method**

When payment details are tokenized through a validation operation, the currency to use was usually (except overrides) chosen as that of the payment provider's company. This sometimes caused compatibility issues if the selected payment method did not support the company's main currency. For example, the SEPA Direct Debit payment method only supports the EUR currency.

This commit allows passing a payment method when getting the validation currency so that only supported currencies can be returned.

---

**[FIX] payment_(buckaroo, stripe): updated the PM based on provider codes**

When processing a transaction, the payment method was searched based on the received code (e.g., 'sepa_debit') that was compared with the `payment` module's generic codes (e.g., 'sepa_direct_debit'). This commit ensures that we now compare with provider-specific codes for Buckaroo and Stripe.

In practice, this mistake had little to no impact as most provider codes match the generic ones, and we fall back onto the payment method selected by the user if we can not find a more accurate one based on the code.

Forward-Port-Of: odoo/odoo#161883

No rounding in the query used to map sale.order.line to the hr.expense, models leads to some records not being able to be linked together, because of floating point errors. Adding a rounding to the key price_unit, and not filtering on price_unit. Then, using the rounded string versions of the price_unit in the comparisons adds a more reliable approach. task-3705179 Step to reproduce: - Change the **[TRANS & ACC] ...** product, setting a cusomer AND a vendor tax of 15% - Create an

No rounding in the query used to map sale.order.line to
the hr.expense, models leads to some records not being able
to be linked together, because of floating point errors.

Adding a rounding to the key price_unit,
and not filtering on price_unit. Then, using the rounded string versions
of the price_unit in the comparisons adds a more reliable approach.

task-3705179

Step to reproduce:
- Change the **[TRANS & ACC] ...**  product, setting a cusomer AND a vendor tax of 15%
- Create an expense using that product with a total amount of 316
- Report -> post the expense (report)
- Reset to draft the expense report
- **The SOL quantities aren't reset to 0**

Reason:
A price_unit used as a float, even rounded can have a floating point error that wasn't taken into consideration
so 14.00001 != 14.00 in the WHERE clause of the query would search for. Hence not matching properly



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

Forward-Port-Of: odoo/odoo#162245
Forward-Port-Of: odoo/odoo#154002

Since [this other commit], web_editor can call IAP to generate text via chatGPT. Unfortunately, an unnecessary param (`version`) was given to IAP leading to a warning on the IAP side `generate_content_from_conversation> called ignoring args <version=X>`. This commit removes this useless param. [this other commit]: https://github.com/odoo/odoo/commit/386a2fdebf429b0318473e596ed9ac0966d9a8b5 Related to task-3383324 Forward-Port-Of: odoo/odoo#162249

Since [this other commit], web_editor can call IAP to generate text via chatGPT. Unfortunately, an unnecessary param (`version`) was given to IAP leading to a warning on the IAP side
`generate_content_from_conversation> called ignoring args <version=X>`. This commit removes this useless param.

[this other commit]: https://github.com/odoo/odoo/commit/386a2fdebf429b0318473e596ed9ac0966d9a8b5


Related to task-3383324

Forward-Port-Of: odoo/odoo#162249

[task-3703209](https://www.odoo.com/web#id=3703209&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#162262

[task-3703209](https://www.odoo.com/web#id=3703209&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#162262

If the "generic" routes (i.e., the ones created from the master data) are company-specific, the user won't be able to create a new comapny anymore. To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Enable all companies 3. Inventory > Configuration > Rules: - For each Manufacture rule: - If its route does not have any company: - Set the route's company equal to the one of the rule 4. Create a new company Error: a Validation Error is raised: "Rule

If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new comapny
anymore.

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
   - For each Manufacture rule:
     - If its route does not have any company:
       - Set the route's company equal to the one of the rule
4. Create a new company

Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."

Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108

OPW-3790512

Forward-Port-Of: odoo/odoo#162189
Forward-Port-Of: odoo/odoo#161820

Commit [1] in 17 introduced a `request.env` instead of `self.env` in `configurator_apply()`. It was not seen and went through the merge. It should not have any bad impact in real use cases as the method is always called from the frontend context and `request` is bound but we have this test [1] which was introduced in 17.1 which is calling `configurator_apply()` in a python standalone unit test, where `request` is unbound. It allowed us to detect the mistake since the nightly was red because of i

Commit [1] in 17 introduced a `request.env` instead of `self.env` in `configurator_apply()`. It was not seen and went through the merge. It should not have any bad impact in real use cases as the method is always called from the frontend context and `request` is bound but we have this test [1] which was introduced in 17.1 which is calling `configurator_apply()` in a python standalone unit test, where `request` is unbound. It allowed us to detect the mistake since the nightly was red because of it.

[1]: https://github.com/odoo/odoo/commit/9f319cbc95f8f4cb76df6f2b82e4b43a74f4b753
[2]: https://github.com/odoo/design-themes/commit/b8aae07df41b44aa78cf39ff6104136556199130

Forward-Port-Of: odoo/odoo#162170

As of April 1, 2024, the migration period set by the Peppol Authority of Finland for the requirement specified in the Peppol Authority Specific Requirements document has ended. According to this requirement, Finnish end users’ Peppol addresses (participant identifiers) must adhere to the ISO 6523 code list 0216 OVT-format. Other address types are not allowed for Finnish end users. See also: [Finland Peppol Authority requirements](https://peppol.org/wp-content/uploads/2023/08/Finland-Peppol-A

As of April 1, 2024, the migration period set by the Peppol Authority of Finland for the requirement specified in the Peppol Authority Specific Requirements document has ended. According to this requirement, Finnish end users’ Peppol addresses (participant identifiers) must adhere to the ISO 6523 code list 0216 OVT-format. Other address types are not allowed for Finnish end users.

See also:
[Finland Peppol Authority requirements](https://peppol.org/wp-content/uploads/2023/08/Finland-Peppol-Authority-Specific-Requirements.pdf)
[Finland Peppol Authority website](https://www.valtiokonttori.fi/en/service/the-state-treasury-is-the-finnish-peppol-authority/#for-service-providers_authority-specific-requirements-in-finland)

It turned out that we have a few others that are no longer used on Peppol.
We will remove those in master as well.
See:
[Peppol codelists](https://docs.peppol.eu/edelivery/codelists/)

no task, reported by the Finnish Peppol Authoirty Team



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

Forward-Port-Of: odoo/odoo#162246
Forward-Port-Of: odoo/odoo#161898

Previously, when the odoo server was running on some Windows installations, it was possible for javascript files loaded directly from the static folder of an addon to fail to run because the Content-Type header was set to text/plain instead of text/javascript. This is because the mimetypes module from the standard library honors the mimetypes from the OS, in the case of Windows it reads a key in the registry, which can be misconfigured to text/plain for .js files. This commit forces the mimet

Previously, when the odoo server was running on some Windows installations, it was possible for javascript files loaded directly from the static folder of an addon to fail to run because the Content-Type header was set to text/plain instead of text/javascript. This is because the mimetypes module from the standard library honors the mimetypes from the OS, in the case of Windows it reads a key in the registry, which can be misconfigured to text/plain for .js files.

This commit forces the mimetype of .js files to text/javascript to solve this issue.

Forward-Port-Of: odoo/odoo#162277
Forward-Port-Of: odoo/odoo#162210

Added a test to verify the behaviour when receiving a negative bill. The invoice gets imported with negative amounts, but it can't be posted. When the user tries to post it, they are prompted to turn it into a credit note with a UserError. Forward-Port-Of: odoo/odoo#141485

Added a test to verify the behaviour when receiving a negative bill. The invoice gets imported with negative amounts, but it can't be posted. When the user tries to post it, they are prompted to turn it into a credit note with a UserError.

Forward-Port-Of: odoo/odoo#141485

Prior to this commit, some attributes such as "data-tooltip" were not exported in /static/src/ templates, while "label" was only exported in them. This commit adjusts the code to use the same list of translated attributes everywhere, fixing the problem and making it less likely to happen again. Task-3872895 Forward-Port-Of: odoo/odoo#162079

Prior to this commit, some attributes such as "data-tooltip" were not exported in /static/src/ templates, while "label" was only exported in them.

This commit adjusts the code to use the same list of translated attributes everywhere, fixing the problem and making it less likely to happen again.

Task-3872895

Forward-Port-Of: odoo/odoo#162079

Followup of odoo/odoo@d6d6bee087fe2d3dc17974054353430c2662aecf : test was not written to be independent from demo data. Also update other tour that fails in no-demo mode as portal user has not enough address value set to continue the tour, compared to demo mode. Task-3871642 Runbot-56554 Runbot-56553 Runbot-61488 Forward-Port-Of: odoo/odoo#162021

Followup of odoo/odoo@d6d6bee087fe2d3dc17974054353430c2662aecf : test was not written to be independent
from demo data.

Also update other tour that fails in no-demo mode as portal user has not enough
address value set to continue the tour, compared to demo mode.

Task-3871642
Runbot-56554
Runbot-56553
Runbot-61488

Forward-Port-Of: odoo/odoo#162021

Issue ----- The packing is not displayed on the delivery slip when: - the product is tracked by lot/SN - the stock.move state = "Done" - "Display Lots & Serial Numbers on Delivery Slips" is activated According to https://github.com/odoo/odoo/commit/c07258c3f27790eea424cee745b2036a3ef0e8c2, packaging information should always be present. Fix ----- We add packaging information to the delivery slip. Also, packaging quantity needs to be rounded up, for example if we have 2.3 packagings,

Issue
-----
The packing is not displayed on the delivery slip when:
- the product is tracked by lot/SN
- the stock.move state = "Done"
- "Display Lots & Serial Numbers on Delivery Slips" is activated
According to https://github.com/odoo/odoo/commit/c07258c3f27790eea424cee745b2036a3ef0e8c2, packaging information
should always be present.

Fix
-----
We add packaging information to the delivery slip. Also, packaging
quantity needs to be rounded up, for example if we have 2.3 packagings,
it will in reality be 3 packagings.

opw-3820304

Forward-Port-Of: odoo/odoo#159448

## Description Add supporting indexes that are used in the queries generated when openning the accounting dashboard. A query is tweaked to hit those indexes and avoid `JOIN` where possible. ## Benchmark Hot loading the default accounting dashboard, default filters and 1 company selected on a staging database with millions of accounting related entries. | | Before | After | |---------|----------|----------| | Timings | 7.32 sec | 1.6 sec | ## Reference task-3805835

## Description
Add supporting indexes that are used in the queries generated when openning the accounting dashboard. A query is tweaked to hit those indexes and avoid `JOIN` where possible.

## Benchmark
Hot loading the default accounting dashboard, default filters and 1 company selected on a staging database with millions of accounting related entries.

|         | Before   | After    |
|---------|----------|----------|
| Timings | 7.32 sec | 1.6 sec  |

## Reference
task-3805835

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

Forward-Port-Of: odoo/odoo#157892

Start a SMTPS server with client certificate authentication. In Odoo configure an outgoing mail server with encryption="ssl/tls" and authentication="certicifate". Load a valid client certificate and key to use with the SMTPS server then test the connection. The connection fails because the client certificate wasn't sent during the TLS handshake. If you're having trouble running a SMTPS server, I made a script here: https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac It use

Start a SMTPS server with client certificate authentication. In Odoo configure an outgoing mail server with encryption="ssl/tls" and authentication="certicifate". Load a valid client certificate and key to use with the SMTPS server then test the connection.

The connection fails because the client certificate wasn't sent during the TLS handshake.

If you're having trouble running a SMTPS server, I made a script here: https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac It uses aiosmtpd, a light pure python smtp server, install it with pip. You'll need to copy your snakeoil ssl key + cert inside your /tmp directory and to expose them to your current user:

    # public cert
    cp /etc/ssl/certs/ssl-cert-snakeoil.pem /tmp

    # private key
    sudo cp /etc/ssl/private/ssl-cert-snakeoil.key /tmp
    sudo chmod 400 /tmp/ssl-cert-snakeoil.key
    sudo chown $USER /tmp/ssl-cert-snakeoil.key

[task-3703209](https://www.odoo.com/web#id=3703209&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#162259

Currently, recalculating `analytic_distribution` requires access to `account.analytic.distribution.model`. This breaks BoM creation for non-accounting users (e.g. MRP managers). This commit fixes the issue by using `sudo()._get_distribution`. 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#1621

Currently, recalculating `analytic_distribution` requires access to `account.analytic.distribution.model`. This breaks BoM creation for non-accounting users (e.g. MRP managers). This commit fixes the issue by using `sudo()._get_distribution`.

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

Before this commit, if there was an error, the PoS stays on the loading page which was confusing for the user. owp-3834647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160113 Forward-Port-Of: odoo/odoo#159710

Before this commit, if there was an error, the PoS stays on
the loading page which was confusing for the user.

owp-3834647

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

Forward-Port-Of: odoo/odoo#160113
Forward-Port-Of: odoo/odoo#159710

**Current behavior before PR:** In systray activity, for some languages, when there were few activities (exceeded a certain length of text), it would break the line to display the labels.  **Desired behavior after PR is merged:** Now, to maintain the design integrity, the text has been truncated to visually display the labels like "aujourd'hu.." and maintain the design consistency. **Task

**Current behavior before PR:**
In systray activity, for some languages, when there were few activities (exceeded a certain
length of text), it would break the line to display the labels.

![image](https://github.com/odoo/odoo/assets/105697657/fd7d35a3-de12-4c8f-8f47-92d29d067913)



**Desired behavior after PR is merged:**
Now, to maintain the design integrity, the text has been truncated to visually display
the labels like "aujourd'hu.." and maintain the design consistency.

**Task**-3869856

Forward-Port-Of: odoo/odoo#162001

- Compute the best resources for a slot only for distinct capacity info and improve performance when updating table booking from 1 to 12 capacities with appointment type with a lot of linked resources (tested on Table Booking without any event booked): Before: ~105s (local time) After: ~15s (local time) This also allows the first slot computation to be a little faster (4s => 3s) - Don't use intervals_overlap in _slot_availability_is_resource_available: ~15s => ~4s (local

- Compute the best resources for a slot only for distinct capacity info and
improve performance when updating table booking from 1 to 12 capacities
with appointment type with a lot of linked resources (tested on Table Booking
without any event booked):
    Before: ~105s (local time)
    After:  ~15s  (local time)
This also allows the first slot computation to be a little faster (4s => 3s)

- Don't use intervals_overlap in _slot_availability_is_resource_available:
    ~15s => ~4s (local time)
It was called a lot because of the default resource calendar and the work intervals
computed from it.

- Single filtered on booking lines for _get_resources_remaining_capacity

Queries count (from profiler - local):

/appointment/4 : ~1500 => ~830
/appointment/4/update_available_slots (capacity -> 12)   : ~7700 => ~455
/appointment/4/update_available_slots (capacity 12 -> 1) : ~1130 => ~430
/appointment/4/update_available_slots (capacity 1 -> 12) : ~7700 => ~455

Queries count (profiler - runbot):
/appointment/4/update_available_slots (capacity -> 12)   : ~1190 => ~130

task-3640599

Forward-Port-Of: odoo/enterprise#59101

When sending an automatic followup, the wrong template is set. This is because of a typo when getting the followup line from the options. Steps: - Have 2 followup levels, 15 and 30 days with 2 different templates and automatic reminder - Have a customer with an invoice overdue by +15 days, and go to his followup report - In the action menu, select "Process Automatic Follow-ups" -> The template used is the one from the 2nd followup level instead of the one from the 1st level. opw-3858013

When sending an automatic followup, the wrong template is set.
This is because of a typo when getting the followup line
from the options.

Steps:

- Have 2 followup levels, 15 and 30 days with 2 different templates
  and automatic reminder
- Have a customer with an invoice overdue by +15 days, and go to his followup report
- In the action menu, select "Process Automatic Follow-ups"
-> The template used is the one from the 2nd followup level instead
   of the one from the 1st level.

opw-3858013

Forward-Port-Of: odoo/enterprise#60843

Within #45236 the sale subscription batching method was rewritten to allow invoices to be consolidated during the cron. However, batch_size was adjusted that caused the code to never actually batch. Because `batch_size` was reassigned to `batch_size + 1` before the search call, the batch check: `need_cron_trigger = len(all_subscriptions) > batch_size` Will always fail as `all_subscription` will never be a larger recordset than `batch_size`. Solution: Don't re-write batch_size and ins

Within #45236 the sale subscription batching method was rewritten to allow invoices to be consolidated during the cron.

However, batch_size was adjusted that caused the code to never actually batch. Because `batch_size` was reassigned to `batch_size + 1` before the search call, the batch check:
`need_cron_trigger = len(all_subscriptions) > batch_size`

Will always fail as `all_subscription` will never be a larger recordset than `batch_size`.

Solution:
 Don't re-write batch_size and instead do `batch_size and batch_size + 1`
 in the search directly.

opw-3846540

Forward-Port-Of: odoo/enterprise#60050

Currently, on large databases (several million move lines), the XAF export can cause a `MemoryError`. The way to bypass this limitation is threefold: 1. Reduce memory usage during query results post processing. - First by removing the unnecessary `res_list`, and directly writing each batch in former `vals_dict`. - Second by updating former `vals_dict` instead of creating an additional (and useless) `values` dictionary. 2. Instead of rendering the entire file at once, the process is now di

Currently, on large databases (several million move lines), the XAF export can cause a `MemoryError`.
The way to bypass this limitation is threefold:
1. Reduce memory usage during query results post processing.
	- First by removing the unnecessary `res_list`, and directly writing each batch in former `vals_dict`.
	- Second by updating former `vals_dict` instead of creating an additional (and useless) `values` dictionary.
2. Instead of rendering the entire file at once, the process is now divided in two steps:
	- Render the header first using Qweb (as before).
	- Generate the journals, moves and move lines manually.
3. Use a generator and stream the content of the file to the user, which will prevent having the entire dataset/file in memory.

task-3816030
opw-3332771

Forward-Port-Of: odoo/enterprise#60707
Forward-Port-Of: odoo/enterprise#58612

**Current behavior:** On the pivot view for the budget analysis view, the percentage column total is the sum of each row's percentage. **Expected behavior:** This value is the mean of all percentages. **Steps to reproduce:** 1. In the Accounting app, create a budget that has a non-zero Achievement value in at least 2 rows 2. Go to *Reporting* -> *Budgets Analysis* and expand the y-axis to show the lines created, observe that the Achievement total is displaying the sum of all percenta

**Current behavior:**
On the pivot view for the budget analysis view, the percentage column total is the sum of each row's percentage.

**Expected behavior:**
This value is the mean of all percentages.

**Steps to reproduce:**
1. In the Accounting app, create a budget that has a non-zero Achievement value in at least 2 rows

2. Go to *Reporting* -> *Budgets Analysis* and expand the y-axis to show the lines created, observe that the Achievement total is displaying the sum of all percentages

**Cause of the issue:**
The percentage field is being aggregated by summation in the read_group() method of the `crossovered.budget.lines` model.

**Fix:**
Calculate the mean instead of the sum.

opw-3761952

Forward-Port-Of: odoo/enterprise#59103

Currently, it's not possible to create a form on `event.event` because website_studio doesn't check whether `/event` already exists. Steps: - Install `website_studio` and `website_event` - Open `Events` - Open `Studio` - Click on `Website` tab - Try to add a new form by clicking on `New Form` - Studio doesn't create a new form because it points to /event which already exists (created by `website_event`). This commit verifies that the route doesn't exist before creating it.

Currently, it's not possible to create a form on
`event.event` because website_studio
doesn't check whether `/event` already exists.

Steps:
	- Install `website_studio` and `website_event`
	- Open `Events`
	- Open `Studio`
	- Click on `Website` tab
	- Try to add a new form by clicking on `New Form`
	- Studio doesn't create a new form because it points to /event which already exists (created by `website_event`).

This commit verifies that the route doesn't exist before creating it.

Pages are served as a fallback when Python routing (`@route`) doesn't
match and there is no attachment matching that url. For simplicity and
performance, we only check that our new page doesn't collide with an
`@route` controller, because we assume that attachments url won't
collide.

see `website/models/ir_http.py` `Http::_serve_fallback`

opw-3778543

Forward-Port-Of: odoo/enterprise#60752
Forward-Port-Of: odoo/enterprise#58504

Currently, an inherited view for `account.view_move_form` targets field `fiscal_position_id` directly with an xpath. While that works for standard modules, it is a very broad xpath that only succeeds in selecting the correct field because it appears before other ocurrences of identically named fields. This commit narrows down the xpath to make it explicit that we target the field located in `account.move`'s "Other Info" page. This fixes an ongoing issue with a customization (described i

Currently, an inherited view for `account.view_move_form` targets field `fiscal_position_id` directly with an xpath.

While that works for standard modules, it is a very broad xpath that only succeeds in selecting the correct field because it appears before other ocurrences of identically named fields.

This commit narrows down the xpath to make it explicit that we target the field located in `account.move`'s "Other Info" page.

This fixes an ongoing issue with a customization (described in the task) while improving readability and extensability of
`account_invoice_form_inherit`.

Task link: [odoo/task#3837027](https://www.odoo.com/web#model=project.task&id=3837027)
Task-3837027

Forward-Port-Of: odoo/enterprise#60462
Forward-Port-Of: odoo/enterprise#60358

In a form view, add a stat button in the button box. Before this commit, the button contained the action's id. It worked on a single DB but when exporting, the id might have changed. After this commit, we put the xml_id of the action instead, which is set when studio=1 is in the context. opw-3824053 Forward-Port-Of: odoo/enterprise#60789 Forward-Port-Of: odoo/enterprise#60298

In a form view, add a stat button in the button box.

Before this commit, the button contained the action's id. It worked on a single DB but when exporting, the id might have changed.

After this commit, we put the xml_id of the action instead, which is set when studio=1 is in the context.

opw-3824053

Forward-Port-Of: odoo/enterprise#60789
Forward-Port-Of: odoo/enterprise#60298

For the custom engine report, _compute_formula_batch_with_engine_custom always uses None for the warnings in the function custom_engine_function, even if a good warnings argument is sent. Now it correctly use the warnings instead of None Forward-Port-Of: odoo/enterprise#60929

For the custom engine report, _compute_formula_batch_with_engine_custom always uses None for the warnings in the function custom_engine_function, even if a good warnings argument is sent.

Now it correctly use the warnings instead of None

Forward-Port-Of: odoo/enterprise#60929

STEP TO REPRODUCE: ================= * Go on Employee App * Select contracts menu item * Select two contracts * Click on actions * Select "signature request" You will have a traceback due to multiple selection. task: 3802377 Forward-Port-Of: odoo/enterprise#59447

STEP TO REPRODUCE:
=================

    * Go on Employee App
    * Select contracts menu item
    * Select two contracts
    * Click on actions
    * Select "signature request"
    You will have a traceback due to multiple selection.

task: 3802377

Forward-Port-Of: odoo/enterprise#59447

**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the portal user. 5) Click on the embedded link(if only read access), double click on it(if write access). **Solution:** Notify the portal user with a toaster notification that only internal members can open that view. **Task**-3082042 Forward-Port-Of: odoo/enterprise#60892 Forward-Port-Of:

**Steps to reproduce:**
1) Open any view of any module.
2) Click on insert a link in the article from Favorites.
3) Now publish the article from the share panel.
4) Copy that link and open it from the portal user.
5) Click on the embedded link(if only read access), double click on it(if write access).

**Solution:**
Notify the portal user with a toaster notification that only internal members can open that view.

**Task**-3082042

Forward-Port-Of: odoo/enterprise#60892
Forward-Port-Of: odoo/enterprise#57347

Version: ----------- saas-16.3 Steps to produce: ------------------------- 1. Open Sales or any other app. 2. Schedule an activity for Request Signature 3. Once the activity is scheduled, click on the Request Signature field 4. In the New signature Request pop-up click on cancel button ->Traceback occurs Issue: -------- A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button. Cause: --------- The error occ

Version:
-----------
saas-16.3

Steps to produce:
-------------------------
1. Open Sales or any other app.
2. Schedule an activity for Request Signature
3. Once the activity is scheduled, click on the Request Signature field
4. In the New signature Request pop-up click on cancel button ->Traceback occurs

Issue:
--------
A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button.

Cause:
---------
The error occurs because when the cancel button is clicked, the onUpdate component is triggered to load and update the ID. However, a special parameter is passed incorrectly, leading to an error.

Fix:
-----
The issue can be resolved by changing the props from onUpdate to reloadParentView, the component correctly reload the parent view upon cancelation, This prevents the traceback error by ensuring that the activity is updated appropriately.

task-3768008

Forward-Port-Of: odoo/enterprise#59981
Forward-Port-Of: odoo/enterprise#58729

When users try to import a file into the ``FEC import`` and the file doesn't have the value of ``key``, an error occurs. This happens because the system requires the value of ``JournalCode`` to be present in the imported file for successful processing. Steps to reproduce: - Install ``l10n_fr_fec_import`` module - Change company from YourCompany to FR Company - Now Accounting -> Configuration -> Accounting -> Journals - Select all journals -> export all journals -> download file in CSV for

When users try to import a file into the ``FEC import`` and the file doesn't have the value of ``key``, an error occurs. This happens because the system requires the value of ``JournalCode`` to be present in the imported file for successful processing.

Steps to reproduce:
- Install ``l10n_fr_fec_import`` module
- Change company from YourCompany to FR Company
- Now Accounting -> Configuration -> Accounting -> Journals
- Select all journals -> export all journals -> download file in CSV format.
- Configuration -> Settings -> Accounting Import -> import -> Click on the ``Import FEC button``
- Upload a file that you have downloaded and Import

Traceback: 
``` AttributeError: 'NoneType' object has no attribute 'replace'
  File "odoo/http.py", line 2252, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1828, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1848, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1826, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1833, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2058, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 42, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 683, in action_import
    return self._import_files()
  File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 729, in _import_files
    for xml_id, record in generator(rows, cache):
  File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 193, in _generator_fec_account_journal
    journal_xml_id = self._make_xml_id('journal', journal_code)
  File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 110, in _make_xml_id
    key = key.replace(' ', '_')
  ```

This commit resolves the mentioned issue by verifying if the key is present; otherwise, it will raise a UserError.


sentry - 4929578488

Forward-Port-Of: odoo/enterprise#59997

Currently, an exception is generated when the user tries to uninstall IoT for PoS. Error: `TypeError: uninstall_hook() missing 1 required positional argument: 'registry'` This is because the commit https://github.com/odoo/enterprise/commit/6b10cc80ea2441b5b2ab86aab52abbf7084d4319 added the uninstall hook at 15, and the uninstall hook requires two arguments in 15.0. But from saas-16.3 uninstall hook require only one argument as 'env'; it is not changed with commit [1]'s forwarded port.

Currently, an exception is generated when the user tries to uninstall IoT for PoS.

Error:
`TypeError: uninstall_hook() missing 1 required positional argument: 'registry'`

This is because the commit https://github.com/odoo/enterprise/commit/6b10cc80ea2441b5b2ab86aab52abbf7084d4319 added the uninstall hook at 15, and the uninstall hook requires two arguments in 15.0. But from saas-16.3 uninstall hook require only one argument as 'env'; it is not changed with commit [1]'s forwarded port.

This commit will fix this issue by providing the argumnet 'env' that is required in the uninstall hook.


sentry-5167509820

Forward-Port-Of: odoo/enterprise#60392

This reverts commit 05c669876a58afa450b946c35e6567d362b2afb5. The issue should be solve with the enterprise commit. https://github.com/odoo/enterprise/pull/60951 Forward-Port-Of: odoo/odoo#162390

This reverts commit 05c669876a58afa450b946c35e6567d362b2afb5. The issue should be solve with the enterprise commit.


https://github.com/odoo/enterprise/pull/60951

Forward-Port-Of: odoo/odoo#162390

Since 584a172274c, the clickall test is failing when clicking on this particular menu. This is due to the fact that the cursor is in read only mode but a temporary `followup_data_cache` table is created causing en error. In the real life, it's not (yet) an issue because the query is retried with a read/write cursor. But in the nightly build, the `bad query`error and the warning are catched. As no solution was found yet to replace this temp table, it's time to blacklist this menu and get ri

Since 584a172274c, the clickall test is failing when clicking on this particular menu. This is due to the fact that the cursor is in read only mode but a temporary `followup_data_cache` table is created causing en error.

In the real life, it's not (yet) an issue because the query is retried with a read/write cursor. But in the nightly build, the `bad query`error and the warning are catched.

As no solution was found yet to replace this temp table, it's time to blacklist this menu and get rid of the noise in the nightly clickall build.

Forward-Port-Of: odoo/odoo#162218