The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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.
closesodoo/odoo#105687
X-original-commit: 46b93da545b52496196624712c44599fd6467f4e
Related: odoo/enterprise#33913
Signed-off-by: Aaron Bohy (aab) <aab@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
closesodoo/odoo#101456
X-original-commit: 33062d9561e9cb4a680dfc36e0c8931a0647e5e8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
make it clear it's expected to be called from the frontend, prefixing it
with action_.
Also split the method to have an utilitary method recomputing all prices,
to use in the tests and/or business code (without the chatter message).
Part-of: odoo/odoo#98068
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.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Improve the filters & actions in booths to ease overview and reporting by:
1. adding and renaming some group by filters
2. adding a price column in the list view of booth event
3. adding a graph and a pivot table view (category/price)
Task-2808962
closesodoo/odoo#95441
Related: odoo/upgrade#3660
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When unlinking booths a check is done on sale orders to prevent their deletion when
a SO is linked and raise a nice error message. However as there is a group on the
field (coming from Sales app) we should sudo the filtered.
Task-2842621
X-original-commit: 9cdc2eec25dd57a74be993b0db0fd81460d6aed6
Part-of: odoo/odoo#94475
Notably using post-install allows to run event_booth tests even when sale
dependencies are installed. Otherwise they cannot run at install due to
required column not being filled in DB.
X-original-commit: aa769df87c0ef0e7ac6924c3e8f5595e8c82eba7
Part-of: odoo/odoo#94475
Steps to Reproduce:
- Connect as Admin
- Install event_booth_sale module
- Give only sales right to Demo user and remove event rights
- Connect as Demo
- Create a new SO
- Add an event booth as product to the SO
- Try to confirm the SO
Issue:
Access error.
Cause:
When comfirming the SO, we also update the selected event_booth
while sales rights are not enough to update event_booth model.
Solution:
Use sudo to update event_booth.
opw-2823555
Task-2842621
X-original-commit: 3f78c6aab091388afaf1e75fc8e9e66db5b8ab4a
Part-of: odoo/odoo#94475
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
PURPOSE
Display the correct price when the tax included option is set in
the website settings.
LINKS
Task-2657480
closes odoo/odoo#89744
Closes: odoo/odoo#89618
X-original-commit: bf5fc98333beae99b94f0b55f0780d6fd18889cb
Forward-port-of: #89277
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Hoste Patrick (pko) <pko@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Forward-port changed since this has been fixed properly in v15.0+
This commit adds the tests only and doesn't contain the fix as previously
LINKS
Task-2657480
Closes: odoo/odoo#89618
X-original-commit: 02932cb2e6ae43c414f222f27080ee7d265c5b39
Forward-port-of: #89277
Part-of: odoo/odoo#89744
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
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
PURPOSE
Before this commit it's impossible to unlink a sale order line containing
a booth product (the ondelete parameter is unset thus default to restrict)
After this commit this bug is fixed.
Further explanation on the task implying a bug on the database setting
the on delete to cascade despite the default value...
LINKS
Task-2749521
PR : odoo/odoo#83685closesodoo/odoo#83767
X-original-commit: e8d96fb1cfd5016f12dc43b988a8a0450bf36a04
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
closesodoo/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
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
PURPOSE
Before this commit when a booth category doesn't have an image a
traceback is shown when accessing to the /booths route.
After this commit a default image is shown when the booth category
doesn't have an image.
SPECIFICATION
To allow the public user to see the booth category image we give
everybody the read permission on the model but restrict some
sensitive fields.
LINKS
Task-2635461
Pr: odoo/odoo#77081
Related: odoo/upgrade#2869
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
PURPOSE
This commit is a first polish for event booth modules. It includes:
- wording
- add currency on price fields
- removing booths tab on event view
LINKS
Task-2635461
PR: odoo/odoo#77081
When booth management is activated, we have a dedicated product for the event
booth. Currently, the product type for this product is set as 'Service'.
This happens after a recent commit[1]. With this commit, we now have a
dedicated detailed product type for event booth, but in data file of
booth product it is set to `service`, which in this case should be
`event_booth`. Apart from that, when creating a booth product for event
booth category, the product type is set as 'consumable', which should
be 'service'.
This commit updates the data for the default booth product and sets the
detailed product type to `event_booth`. And this commit also passes
correct context when creating a product for the event booth category so
that the product type is now set as 'service'.
commit[1] - https://github.com/odoo/odoo/commit/3d7b9bbf27298dc7f2f7e61a13120988f9bd422a
Task-2648950
closesodoo/odoo#77146
X-original-commit: e466430e44844339f1ec9f2ed3c79f6f34501291
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This module allows to sell booths to partners by setting a product and a price
to the booths categories. When selling booths on a sale order it will open the
product configurator and ask the event, booth category and booths.
It's only possible to select booths belonging to the same category for one sale order line.
A new model is introduced by this module :
- Booth Registration that allows multiple registrations to a booth.
The booth will be set unavailable when the sale order linked to the registration is paid.
All the others registrations will be cancelled
LINKS
Task-2318655
Closes : odoo/odoo#71104
FrancoisGe