6a366b21 was aiming to uniquify translations, this is not usefull
anymore because of unique constraints added on ir_translation table.
Removing the subselect slightly improve performances.
This fixes 957c78b98f to make it
compatible with 55e1b44492.
Upon record creation, we do not set a company-dependent field when its
value is the same as its default in `ir.property`. Here we take into
account that `field.default` does not necessarily return that value.
closesodoo/odoo#36905
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
various UI changes
------------------
* renamed "test import" button to "test"
* move relation fields thing to debug mode
* remove "Defer parent/child computation" option as it was deprecated
/ removed from the backend in
80f1ac3599, turns out this checkbox
existed inactive for longer than it's been of any use (added in
68cb2ade09 on 2017-11-29, made
non-operating on 2018-01-24, that's so sad)
batching
--------
* add support for batching imports (skip & limit parameters)
* modify client to use batched imports & properly adapt responses so
it still looks like a single import for the client (more or less)
e.g. update row numbers in error messages, etc...
* properly handle partial imports though
* disable usual loading throbber to have a single progress
notification displayed continuously throughout all the batches: the
normal throbber only shows after 3s of waiting for an RPC response,
so it would keep flashing in and out (appear 3s into a batch's
import then disappear at the end only to reappear 3s into the next
batch's loading)
NOTE: the limit is row-wise. If a record straddles the limit (because
of nested O2M records), the record is imported in full and the "next
row" is whatever row follows the record. This means a limit of 10 can
lead to an import of 17 lines, and as the progress indicator is in
records# the increments can jump around.
Task 2059448
Purpose
=======
On a record creation, a valid and user friendly error message is raised
when a sql constraint is violated. (Eg: 'The start date must be anterior
to the end date').
On a record modification, this is not always the case anymore, since the
latest ORM modifications.
Eg: Write on a leave with a date_from > date_to, you got the postgreSQL
error, which is not understable by a classic human.
This is due to the fact that the error is correctly catched and logged,
but the result is set into the cache, triggering the execution of computation
methods, and calling _validate_fields. It is highly probable that a flush
is done in the constraint method (search, read, ...). In that case the
postgreSQL error is converted into a ValidationError, with a stringified
version of the IntegrityError, and thus is not catched by the check wrapper.
Determine `model._rec_name` before the dependencies of the fields. The
compute method of the automatic field `display_name` uses a callable
depends that retrieves `model._rec_name`.
closesodoo/odoo#36484
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This prevents a bunch of queries that are useless when creating a
record. Indeed, right after a record has been created, no other record
has a many2one reference to it. In other words, inversing a many2one
field from the record just created always gives an empty recordset.
Those useless inversions generate about a dozen queries when creating a
`res.partner`, for instance.
This saves queries, but not much time.
closesodoo/odoo#36566
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Assigning `check_company=True` to a field will
- set a default domain filtering the companies
- allow to call `_check_company` on the records to ensure the domain is
respected
Setting `_check_company_auto = True` on a model will ensure
`_check_company` is called at create and write, enforcing the multi
company domain.
Joint work with Raphael Collet <rco@odoo.com>
task-1985992
Before this commit, creating a record of a model with at least one
property/company_dependent field would trigger the field's inverse
method regardless of whether an actual value was being passed in for the
field or not.
This means that if no value was given or if the value was the same
as the default value, we would waste precious time in the property
field's inverse method.
With this commit, we do not call the inverse method if:
1) there is no value for it in the vals dict (use default)
2) the value in the vals dict is the same as the default value
As an example, when creating a res.partner record while having account
installed (which introduces a property field in res.partner), the
creation time goes from 24ms to 14ms.
closesodoo/odoo#36267
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
The selection values of a selection field are now stored in database in the
model ir.model.fields.selection
This will allow to have a modular approche on selections and each selection
is now linked to the module that declared it.
Previously to this change, the selections were linked to the field, meaning
uninstalling a module had no impact on the selections stored on database.
With this change, the selections will now be translated in the correct module
(having an external id) and the records having a used selection will now be
reset to null.
closesodoo/odoo#30228
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
If a db is in single lang (en_US or not) but still has translations, the
translation should be updated in addition to updating the referenced record
Add tests to formalise the expected behaviour:
If one language only (en_US or not), when writing on a translatable field:
- record field should updated
- value of potential existing en_US translation should be updated
- src of potential existing translations should be updated
- no new translation should be created
If en_US and fr_FR, when writing on a translatable field in en_US:
- record field should updated
- value of potential existing en_US translation should be updated
- src of potential existing translations should be updated
- new en_US translation should be created if was not present
If en_US and fr_FR, when writing on a translatable field in fr_FR:
- record field should not be updated
- value of potential existing fr_FR translation should be updated
- src of potential existing translations should not be updated
- new fr_FR translation should be created if was not present
Adapt test_new_api test
get_installed is ormcached, just putting active = True is not enough
Instead, make sure the field src is always up to date
Add tests
Changes in _write:
- Replace _set_ids (to be deprecated) call by _upsert_translations as it works
in batch
- Call _upsert_translations for any language, including en_US
In case an English translation already existed for a record, only the master
value (on the reference record) was updated but the user kept seeing the
translation value (was revealed 73a7534bfc).
- Read src_trans without language
Similar as above, if an English translation already existed, the translation
was used for the result of the read and not the new value that has just been
inserted into the database
- Add _set_source method
When updating a master record of a translated field, the src field must be
updated, including in different languages.
Before it was ok that the src field was out of date as the source was computed
Changes in copy_translation:
- set src as the new value without lang
update the comment to reflect reality since 489494e733
src will contain the English version if no changes were made and it will
contain the modified value if copy was overriden
Changes in upsert_translations:
- Do not force a module, comment, state
Only src, res_id, name, value and lang must be given. Optional values will no
longer be set to null if not given
Using api.constrains should be used instead
Simply leave a warning in case a model uses a non-empty attribute
`_constraints`.
closesodoo/odoo#34679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Currently when clicking on 'Archive' or 'Unarchive' on the list view,
we write directly on the record {'active': False}, instead of calling
toggle_active. Missing that way implementation of numerous business cases.
Example
- Archive a record --> archive its next activities
- (Un)Archive a user --> (Un)Archive its partner
- (Un)Archive a product variant --> (Un)Archive its template if
there is only one variant
- Archive an employee --> Open a wizard to choose an exit plan + describe
the departure reason
- Archive a route --> Archive its procurement rules
- ...
Specification
=============
- Call toggle_active instead of write when calling toggleActive in the web
client.
- On the other hand, use actionArchive and actionUnarchive to apply the
toggle action on the related records only.
Store the SQL constraint message directly in the field `message` of the
corresponding `ir.model.constraint` record, and manage translations from
there. Those records are given an XML id in order to be tracked in PO
files. The translation type 'sql_constraint` is removed.
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
When the model has several x2many fields which are non-disjoint, the web
client sometimes invokes `onchange` with inconsistent data: a line
appearing in two x2many fields with different values for a subfield.
The method must deal with that inconsistency and return correct data to
the client.
Comparing the length of the recordset is not enough for determining if
there is changes on m2m.
This also fix the merge of f14ae73a98 and
d0bb596f1d
Oversight of previous forward-port.
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33943
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
Raphael Collet