Computing the recurrences of a task repeating every X months until a certain date generates too much dates

Steps to reproduce:
1. Install Project
2. Go to Settings > Project > Tasks Management and enable Recurring Tasks
3. Open any project in the Project app and create a new task then edit it
4. Enable the Recurrent field of the task
5. In the Recurrence tab, edit:
   - Repeat Every: 6 Months
   - Until: End Date: one year from now
6. The recurrence message says there are 11 tasks but there should only be 2

Solution:
Generate the recurrences until the `repeat_until` date is reached if the `repeat_type` is 'until', otherwise generate as much recurrences as the count
Also relax the constraint on the `repeat_day` and `repeat_until` to not raise an error if `repeat_until` is the last day of the month

Problem:
The recurrence of a task with `repeat_unit` month and `repeat_interval` different than 1 with a `repeat_type` until creates too much tasks, exceeding the `repeat_until`

opw-3076593

Forward-Port-Of: odoo/odoo#107836
Forward-Port-Of: odoo/odoo#106596

This revision is related to odoo/enterprise#33088

The needs is the same:
While using Studio,
instead of removing the node from the view
when the user is not part of the group,
set the node as invisible.
This is so the xpath expressions computed by Studio takes into account nodes which are removed from the view when the user is not part of the group required by the node.

e.g.
```xml
<form>
    <group>
        <field name="name"/>
	<field name="currency_id" groups="base.group_multi_currency"/>
	<field name="foo"/>
    </group>
</form>
```

With the above view, if you want to add a new field after `<field name="foo"`/>
and the `currency_id` field node is removed from the view during the post-processing of the view
because the user doesn't have the group,
Studio computed the xpath expression with `field[2]`, and then the new field was mis-placed,
it was before the `foo` field instead of after.
The strategy is to let the nodes, as invisible,
for which the user doesn't have the groups
so the xpath expression is correctly computed
for the view as it is stored in the database/
before the post-processing step removing the nodes.

The above revision applies this strategy for
nodes other than `<field/>` and `<t/>`.

The `<field>` were not included because it was,
at that time, believed it wasn't necessary.
Even though the index was wrong as demonstrated
in the above example, it was then converted
with the expression `field[@name="foo"]`
instead of `field[2]`, and therefore it was
fine not to include the `field` nodes
in the strategy.
Also, fields were not included in the strategy
because for them, if the `groups` is set
in the Python model
e.g.
```py
currency_id = fields.Many2one(..., groups='base.group_multi_currency')
```
Attempting to read them while you don't have the group will lead to an AccessError exception.
And there was no way to display the field as invisible in the view without the web client to try to read its content.

Unfortunately, it isn't the case,
as demonstrated by the tours included in this revision, field nodes must be included in the views, as invisible, so Studio can compute correctly the xpath expression.

This revision therefore aims to apply the same strategy for `field` nodes, make them invisible instead of removing them from the view when the user is not part of the groups. The revision takes care to override the web client so it doesn't try to read the value of group-protected fields when the user doesn't have the group.
So the field, with the label and everything,
is included in the view, but its content/value is left empty, as the user cannot read the content.
Technically, there won't be many cases, because
users editing views using Studio are admins,
and in most-cases admins have access to these group-protected fields. Having a field group-protected to which the admins do not belong doesn't happen that often.

Co-authored-by: kebeclibre <lpe@odoo.com>

Forward-Port-Of: odoo/odoo#107429

When it comes to closing POS sessions, both the frontend and the backend currently have some way to prevent the same operations from executing simultaneously because of repeated clicks. `closeSession` in the frontend has a `closeSessionClicked` boolean that prevents the operation from triggering multiple times at once. `close_session_from_ui` in the backend checks if the session state isn't already `closed`.

A flaw in the current logic is that `update_closing_control_state_session`, which is called by the frontend before `close_session_from_ui`, doesn't check the session state before writing it to be `closing_control`. This means that if you time things in such a way that the `closeSession` logic in the frontend triggers again right after it finishes, it will call
`update_closing_control_state_session` and `close_session_from_ui` again, which will happily close the session again, duplicating stock moves and account moves resulting from it.

This fix has `update_closing_control_state_session` check if the session is already closed and raises a UserError if so. This prevents the duplicate closings and records from happening.

There were two variants in the UI I observed when the issue occurred: the first is when the repeated execution of
`update_closing_control_state_session` and `close_session_from_ui` successfully finished. In that case the session would be closed with duplicate stock moves and journal entries.

In the second variant, from the repeated calls only `update_closing_control_state_session` executed but not `close_session_from_ui`. This could happen if the timing of the frontend was such that it redirected to the POS dashboard before it was able to call `close_session_from_ui`. In that case, the session would be in the `closing_control` state, which is visible in the POS dashboard . If the user then closed the session, it would be closed twice and the duplicate records would again be created.

opw-2988701

Forward-Port-Of: odoo/odoo#107873

The table of content (TOC) has two mechanisms that interest us here:

The first one is ScrollSpy (from Bootstrap) which allows (among other
things) to bold the menu items according to the scroll. The second one
is a mutation Observer which is implemented to regenerate the menu when
the content of the TOC changes.

This being said, when we edit the TOC and scroll at the same time, there
is a race condition that makes ScrollSpy want to add a class to a menu
item while this menu has just been regenerated by the observer. The
error is only visible since the migration from bootstrap 4 to bootstrap
5 because to add the class, bootstrap 4 did it with the JQuery
`addClass()` function which does not cause an error if the element on
which it is called does not exist. Now, bootstrap 5 does the same thing
in pure JS with `classList.add()` which causes an error if the element
on which it is called is not defined. This commit fixes this error by
disabling the ScrollSpy when you regenerate the menu.

Steps to reproduce the error:
- drop a table of content block
- drag a snippet around and go over the drop zones

=> traceback. It can appear directly or after some tries.

While this bug was being fixed, another one was discovered:

Since [this commit], when dropping several "table of content" blocks on
the same page, it was impossible to save. This commit solves this
problem.
Steps to reproduce the resolved bug:
- In edit mode, drop two TOC blocks
- Click on Save

=> the UI is blocked

[this commit]: https://github.com/odoo/odoo/commit/06b03ba5ef8375b1236f6ecb52ac468124e910ba

task-2948895
opw-3047375

Forward-Port-Of: odoo/odoo#98977

This commit aims at:

1. Fixing a bug where the invoice would be uploaded in the wrong journal

To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill

2. Letting the FacturX move type override the user-chosen move type

Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.

3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication

Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.

4. Adding a 4th button in the Documents app to create a Vendor refund

Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.

5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view

Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.

Task id 2961932

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

Forward-Port-Of: odoo/odoo#101280
Forward-Port-Of: odoo/odoo#99247

Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and register for the event.

Issue:
 The price in the cart is shown in the main currency

Solution:
[website_event_sale] There is an initial issue which when it calls '_compute_price_reduce'. We compare, 'product.lst_price' (in product.currency) and 'product.price' (which has been converted to the pricelist.currency).
In order to compare apples with apples, a conversion is applied to have the 'product.lst_price' in the same currency.

After that, we have kind of a coherent behaviour in the sense that 'ticket.price_reduce' is in the same currency as 'ticket.price'.
Thereafter, a conversion is applied (if the pricelist.currency is different) to get the expected  amount.

The same reasoning is applied to [website_event_booth_sale].

Note: 'list_price' has been changed to 'lst_price' in Booth to have the same logic between Event and Booth

opw-2766997

Forward-Port-Of: odoo/odoo#101375
Forward-Port-Of: odoo/odoo#85640

Start a server without a -d and with a --dbfilter that allows for multiple database. Make sure one of the database has the `base_import_module` addon installed. Create an empty module using scaffold and deploy it to the server, make sure to provide the `--db` argument to the deploy command.

It zips the file and attempt to upload it but it fails for a 404 page not found error.

The problem is that the controllers of base_import_module are only accessible when the client is connected to a database. It must first connect to a database (to have a db in his session) and then access the controller.

The /web/login route is an example of a rather cheap route to get that is both accessible without being connected to a database and that takes a `?db=` argument to connect to one. Using that route, we can ensure that we are connected to a database prior to uploading a module.

Closes #104589

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#107279
Forward-Port-Of: odoo/odoo#104642

Currently `_compute_bulk_weight` and `_compute_weight` go through each picking in self and each stock_move_line in picking.move_line_ids to compute the pickings' weights.

This can be slow when there are lots of move_lines by picking as the field cache will be filled by the move_lines records and `uom._compute_quantity` will be called once by move_line.

This is especially true for pickings with SN-tracked products. For SN tracked products there will be one move_line by product_qty (so a picking with 1 SN tracked product with a qty of 100 will have 100 move_lines). In this case doing a read_group yields the highest speedup.

Adding an `orderby = 'qty_done asc'` in the read_groups prevents the default ordering by groupby fields. This default
ordering may require to join on some other tables to retrieve the required columns. In this case, leaving the default
orderby leads to a query with 4 Left Joins (on product_product, product_template, ir_translation and stock_quant_package).
Since the ordering is not really useful here, we can "drop" it by setting a dummy one. The resulting `GROUP BY` query
is 2-3 times faster that way.

Following the same reasoning a search_count is done in `_compute_packages` before retrieving package.move_line_ids.
When package.move_line_ids.result_package_id is empty doing a count is much faster as it avoids calling _in_cache_without for the package move_line_ids. The search_count overhead is negligeable in the other case so adding it leads to an overall speedup on average.

#### speedup

15.2 customer DB with 19 300 stock_pickings, 913 000 stock_move_lines, 208 products (5 by SN, 155 by lot).
stock_move_lines by picking (min, avg, max): 1, 48, 71832.
distinct product_id by picking (min, avg, max): 1, 2, 138. 

Receipts (picking_type_id = 7) ListView search_read time increasing search_read limit.
No stock_move_line with result_package_id != NULL for this picking type.

| Limit | Before PR | After PR |
|:-----:|:----------:|:---------:|
| 5 | 140ms | 116ms |
| 25 | 1.15s | 161ms |
| 80 | 8.80s | 266ms |
| 183 | 42.23s | 447ms |

This benchmark comes from a 15.2 DB but the results should be close for a 14.0 DB.

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

Forward-Port-Of: odoo/odoo#107892
Forward-Port-Of: odoo/odoo#107558

This PR aims at:

1. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication

Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.

2. Adding a 4th button in the Documents app to create a Vendor refund

Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.

Task id 2961932

Community PR:https://github.com/odoo/odoo/pull/103427

Forward-Port-Of: odoo/enterprise#31846
Forward-Port-Of: odoo/enterprise#30879

This revision is related to odoo/enterprise#33088

The needs is the same:
While using Studio,
instead of removing the node from the view
when the user is not part of the group,
set the node as invisible.
This is so the xpath expressions computed by Studio takes into account nodes which are removed from the view when the user is not part of the group required by the node.

e.g.
```xml
<form>
    <group>
        <field name="name"/>
        <field name="currency_id" groups="base.group_multi_currency"/>
        <field name="foo"/>
    </group>
</form>
```

With the above view, if you want to add a new field after `<field name="foo"`/>
and the `currency_id` field node is removed from the view during the post-processing of the view
because the user doesn't have the group,
Studio computed the xpath expression with `field[2]`, and then the new field was mis-placed,
it was before the `foo` field instead of after.
The strategy is to let the nodes, as invisible,
for which the user doesn't have the groups
so the xpath expression is correctly computed
for the view as it is stored in the database/
before the post-processing step removing the nodes.

The above revision applies this strategy for
nodes other than `<field/>` and `<t/>`.

The `<field>` were not included because it was,
at that time, believed it wasn't necessary.
Even though the index was wrong as demonstrated
in the above example, it was then converted
with the expression `field[@name="foo"]`
instead of `field[2]`, and therefore it was
fine not to include the `field` nodes
in the strategy.
Also, fields were not included in the strategy
because for them, if the `groups` is set
in the Python model
e.g.
```py
currency_id = fields.Many2one(..., groups='base.group_multi_currency')
```
Attempting to read them while you don't have the group will lead to an AccessError exception.
And there was no way to display the field as invisible in the view without the web client to try to read its content.

Unfortunately, it isn't the case,
as demonstrated by the tours included in this revision, field nodes must be included in the views, as invisible, so Studio can compute correctly the xpath expression.

This revision therefore aims to apply the same strategy for `field` nodes, make them invisible instead of removing them from the view when the user is not part of the groups. The revision takes care to override the web client so it doesn't try to read the value of group-protected fields when the user doesn't have the group.
So the field, with the label and everything,
is included in the view, but its content/value is left empty, as the user cannot read the content.
Technically, there won't be many cases, because
users editing views using Studio are admins,
and in most-cases admins have access to these group-protected fields. Having a field group-protected to which the admins do not belong doesn't happen that often.

Co-authored-by: kebeclibre <lpe@odoo.com>

Forward-Port-Of: odoo/enterprise#34752