The goal of this commit is to avoid the execution of code depending
on the validity of the save of a Record.

Before this commit, several override save functions in Record execute
code after the record's save without checking if the record's save has
taken place.

Override before:
export class NewRecord extends Record {
    async save() {
        const isSaved = await super.save(...arguments);
        // doAction
        return isSaved;
    }
}

Override after:
export class NewRecord extends Record {
    async save() {
        const isSaved = await super.save(...arguments);
        if (isSaved) {
            // doAction
        }
        return isSaved;
    }
}

How to reproduce the problem:
    Go to a form view with a Record having its save override function.
    Edit a record in such a way to have an invalid field
    Click on the save button

Before this commit:
The doAction is executed

After this commit:
The doAction is not executed

Real use case
- Go to the form view of a lead in CRM
- Change stage
- Clear the name field
- Click on save button

Before this commit:
A call to get_rainbowman_message is made

After this commit:
No call to get_rainbowman_message is made.

closes odoo/odoo#105468

Related: odoo/enterprise#33817
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This commit fixes an issue where if a ticket is free, the registration would
still "need to be paid" by the attendee.

This behavior is contradictory for a free ticket, so the attendee now has to
pay the ticket if it is not paid and is not a free ticket.

task-3012928

closes odoo/odoo#105552

X-original-commit: 2b0587fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

closes odoo/odoo#102045

Related: odoo/enterprise#32243
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce:
- Add an event product to the template order
- Create an so
- Select the template order you just created

Expected behavior:
you get a popup to configure the event

Current behavior:
There is no popup and the product event is not
fully configured

opw-2971168

closes odoo/odoo#101436

X-original-commit: 33062d9561e9cb4a680dfc36e0c8931a0647e5e8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

And stop relying on dumb event_ok field, when the product_type already 
holds the information (recently moved from sale_stock to sale).

Task-2918791

Part-of: odoo/odoo#101304

closes odoo/odoo#100893

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

closes odoo/odoo#100573

Related: odoo/enterprise#31507
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Methods ordering (after place of call)
String guidelines (double quoted strings for strings shown to the user)

Part-of: odoo/odoo#98068

Just doing the summer file cleaning. Move mail data into files named based on
their model, easing maintenance and searching for those data.

Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)

Part-of: odoo/odoo#98661

Cancel or properly wait for save to finish, depending on tour.

Part-of: odoo/odoo#96517

TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
  to improve perfs.

_______________________________________________________________________

The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
  `write`
* by saving when switching tabs on the Invoice form, to synchronize
  before showing the values

This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
  intercompany, ...)
* the performance for invoices with many lines improves drastically, going
  from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
  instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
  which was unexpected and needed to be managed manually in all the
  onchange methods

This means that:
* Some fields need to be exclusively computed on journal entries values
  or invoice values, more specifically the Tax Summary widget.
  It is now
    - computed from entry lines, when opening the view
    - computed from invoice lines when changing those, because the tax lines
      will need to be recomputed anyways, erasing previously set values
    - set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
  (i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
  This is because such a behavior was undefined (how is changing the balance going
  to affect the unit price? How is the amount currency going to affect it?)

_______________________________________________________________________

Implementation Details
----------------------

The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.

Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)

By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`

The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.

Performances
------------

You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.

```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
    self.env['account.move'].create([
        {
            'move_type': 'out_invoice',
            'partner_id': random.choice(partners),
            'invoice_line_ids': [
                Command.create({
                    'name': f'line{i}',
                    'product_id': random.choice(products),
                    'tax_ids': [Command.set([random.choice(taxes)])],
                })
                for i in range(nline)
            ]
        }
        for j in range(nmove)
    ])
                                                             # After  | Before
print(timeit("create(1, 1)", globals=globals(), number=1))   # 0.11   | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76   | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56  | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03   | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99   | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44  | 79.55
```

Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)

Why this commit title?
----------------------

Someone told me that this was the perfect way of naming your commits.
c04065ab

task-2711317

closes odoo/odoo#96134

Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>

The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.

We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).

[1] odoo/odoo#92475

Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>

Automated change made by a lot of RegEx to change all think that is
possible to automate.

https://getbootstrap.com/docs/5.1/migration

Task ID: 2766483

Part-of: odoo/odoo#95450

closes odoo/odoo#93246

X-original-commit: 5ff6d185f70650c26c28a6aef7dd37c859ab58d2
Related: odoo/enterprise#28218
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

As an event manager, it can be difficult to estimate how much of the revenue
was generated by the events. To give clear insights, we will add new reports
to the 'event' module.

With those new reports, the user can group the revenues by event (type),
ticket, product, etc. The user will then be able to quickly see which tickets
and events are the most profitable ones. The reports will be accessible only if
the user installed the 'sale' module.

Task-2679881
See odoo/enterprise#24472

Part-of: odoo/odoo#81583
Co-authored-by: Florian Charlier <flch@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>

With stored computed seat attributes, the database can be flooded with update
queries for the stored values for the event (ticket) seats computations (such
as reserved, expected, and available seats).
This can especially occur when a communication is sent to many people about
an event with a registration link, many users may want to register at the same
time, possibly resulting in concurrent_update errors.

In this commit, we remove the `store=True` attribute of those fields, and
therefore remove the Reporting/Event feature depending on them and rewrite some
domain searches and _compute fields in the event and event_sale modules.

This also impacts the way constraints are enforced on the number of
registrations vs defined maximum as no stored value is directly available.

For performance reasons, all events and tickets are now shown on backend form
views, with seat availability added in their displayed name.

Misc
To avoid delaying the inevitable, the Event configurator modal/wizard now
validates event/ticket consistency at closing.

The UI of the RegistrationEditor wizard is also improved:
* A warning alert will tell users that free registrations were not confirmed
because of insufficient seat availability.
* A first step to better explain the consequences of the actions taken on the
modal was to be taken, here via the description and buttons wording.

Tests
Query counts are (indeed reduced) and updated. However, as local testing with
`test-tags=/test_event_full` ("tef_only") is currently not reliable, these
values were updated by applying the same change from the commit as the one seen
for the runbots, while a "?" is appended to show this uncertainty.

Task-2654816
See odoo/upgrade#3118

Part-of: odoo/odoo#81583

When using the product configurator for event tickets the
price was not updated when picking a ticket with a different
price.
This of course is to the desired behavior.

This commit makes sure the unit price is correctly
recomputed when the ticket is modified on the SO
line.

Task - 2767301

closes odoo/odoo#85208

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit, when cancelling a SO, the wizard opened only when
there were draft invoices or delivered picking in the order.

In order to complete the notification flow of the SO and avoid
unexpected  cancellation of orders, the user must now confirm
cancellation and gets to possibility to send an email notification.

task-2660895

Part-of: odoo/odoo#81569

Replace each t-esc by t-out since it's now deprecated in templates

task-2458013
COM PR: odoo/odoo#78049
ENT PR: odoo/enterprise#21543

This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases

closes odoo/odoo#84908

Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>

Reproduction:
1. Start the process to buy (register) 2 tickets for an event
2. Go back to “review order” and reduce the quantity to 1
3. Sign up with a new portal user and create an account
4. Change the number of tickets to 2

Reason: the seats_expected in event.event has a different computation
logic from the attendee_count in sale.order. In event.event, the
seats_expected does not count canceled registrations. In sale.order, the
attendee_count counts the canceled registrations. But they are both
shown as "Attendees" in the statinfo widget of form views

Fix: Added a domain condition to filter out canceled registrations when
computing attendee_count in SO

opw-2739310

closes odoo/odoo#85491

X-original-commit: 88fecdc4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Discount wasn't computed the same way in backend sale flows and e-commerce flows.
Now the pricelist discount policy will be considered in the core logic of
event_sale.

Part-of: odoo/odoo#82374

Owl 2 changelog: https://github.com/odoo/owl/blob/a9f29c4caad4f32d06be1ec4780572825781cd9b/CHANGELOG.md



Part-of: odoo/odoo#80156
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>

Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)

Review of indexes on all objects.

closes odoo/odoo#83015

Signed-off-by: Fabien Pinckaers <fp@odoo.com>

* make sure full content is translated in partner language
* drop useless product param (use line product_id field instead)
* delegate order lines name computation to computes for ecommerce carts

closes odoo/odoo#82620

Related: odoo/enterprise#23432
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======

The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities

Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.

This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.

* remove error prone product param
always use the product of the line instead.
* also move the method near the place where it's called

Use freezegun as it is more easy to use and allow to remove a lot of extra
boilerplate. Indeed manually patching datetime is a PITA as a lot of imports
have to be patched.

A custom patching has to be done for create_date, as it is done using a value
stored on the cursor (cr._now), based on SQL now. As it has nothing to do
with standard python library it cannot be patched using freezegun.

Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)

Part-of: odoo/odoo#81068

Purpose is to have a common event class for users and useful stuff (customers,
products, ...) but lessen usage of common test data through sub modules.
Indeed having a "global event type" test data updated in various addons is
actually complicated to maintain.

Sub add-ons are updated to use mainly the ``EventCase`` test class holding
users and side data. Data specific to those modules (event type with some
specific configuration notably) is created and used in tests in the given
module only, and not through generic event_type_complex and event_0 test
data anymore.

With this commit tests are more localized to their add-on and modifying data
in a given add-on has less chances to have unwanted side effect in other event
submodules unit tests.

Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)

Part-of: odoo/odoo#81068