Let's assume a one2many field (editable list) in a form view with
a many2many (e.g. many2many_tags), and an onchange on the one2many
such that, when a row is added to the relation, the server returns
update commands for (a subset of) the records being already in the
relation. For thoses updated records, the many2many field needs to
be read (the onchange only returns the ids in the relation).
Before this rev., the many2many field was read independently for
each record in the one2many. This could cause a performance issue
on large relations. For instance, this was the case on
account.invoice records with a lot of lines.
Issue 2027356
closesodoo/odoo#34785
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Scenario:
We have the following models:
class A:
submodel_1_ids = fields.One2Many(B)
submodel_2_ids = fields.One2Many(B)
class B:
parent_model = fields.many2one(A)
name = fields.Char()
and the following onchange on class A:
api.onchange(submodel_1_ids)
def onchange_submodel1(self):
// add newline to second o2m
submodel_2_ids = submodel_1_ids
api.onchange(submodel_2_ids)
def onchange_submodel2(self):
do_smth
In a form view containing both o2m fields (editable="bottom" lists):
1) add a line on first o2m -> the onchange adds the same line on
the other o2m
2) add a line on the second o2m
Before this rev., the line (added in (2)) wasn't added at the bottom
of the list, and the row in edition wasn't the newly created one.
The issue occurred because we couldn't retrieve the datapoint
corresponding to the other line (the one created by the onchange on
the first o2m), and we thus created another which was put at the
end of the list. Then, the BasicModel messed up the sort of the
records because it couldn't match the virtual id of that new record
with the ones in orderedResIds.
We fixed the issue by preventing the model from creating a new
datapoint after the onchange, by using 'ref' instead of 'res_id' to
retrieve the one that already exist.
closesodoo/odoo#34493
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Let's assume a one2many field in a form view with a default value
with commands 4 (link to). Before this rev., when saving the record,
the BasicModel generated a command 4 and a command 1 (update) for
each record, with the values of the record (directly coming from DB).
This can cause an issue when the related record can't be edited
(e.g. a posted journal entry in accounting).
closesodoo/odoo#33797
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
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
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 we open any x2m record (in a FormViewDialog), there is a "Remove"
button to delete/unlink the opened record from parent.
This button is placed besides "Discard" button and it creates little
confusion in some cases. For example, in list view, there's already a
bin / 'x' icon depending on the field type using which people are used
to delete/unlink the record. And when they open a record, they might
accidentally click "Remove" button instead of "Discard".
To avoid this, now we won't show "Remove" button when we open record from
x2many list view. However, we have to keep this button in case x2many of
kanban as there's no other way to remove the record.
task-1886913
closesodoo/odoo#34333
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.
Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.
closesodoo/odoo#32408
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Assume an x2many editable list where the user edits a record (input
field), and then clicks on 'Add a line' (and keeps it pressed for a
while, before releasing the click).
When the 'mousedown' event occurs, the 'change' event is triggered
on the edited field, and (once potential onchanges have been
applied), the list is updated, i.e. all rows except for the one
being edited a re-rendered.
However, the 'Add a line' handler listens to the 'click' event,
which never occurs if we release the click after the rows have been
re-rendered.
This is an issue for every rows, not only 'Add a line', but for
data rows, the issue is already present in former versions, and is
not that easy to fix). The 'Add a line' case is a consequence of
the recent work on list views (see 234d92c4f0), so we can fix it
independently.
Task 1915702
Before this commit when user want to add multiple record at that time
they only allow to add one record at a time.
After this commit user can add multiple record from search more wizard.
Added function _getSearchCreatePopupOptions so that it can be overridden
in FieldMany2ManyTags, options for FieldMany2ManyTags will differ, like
FieldMany2ManyTags SearchCreateDailog should have multi record selection,
Many2ManyTags' SelectCreateDialog should display record other than selected
This commit is related to task id: 1945912
closesodoo/odoo#32453
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Rev. a3489be33 removed this feature to fix a bug (when the single
line many2one, e.g. a product, is too long and displayed over
several lines). However, we (fp) still want this for res_partner
many2ones with show_adress.
This rev. re-introduced the feature without re-introducing the bug.
closesodoo/odoo#33139
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This rev. changes the layout of *editable* list views to a fixed
layout. This means that we are now responsible of the width of
each column. To do that, we associate with each field type a
factor, and the higher the factor is, the larger the column will
be (w.r.t. the others). This default value can be overriden in the
arch.
The fixed layout allows to remove the absolute positionning of
widgets inside editable lists (done in the next commit).
Part of task 1915702
Co-authored-by: Martin Geubelle <mge@odoo.com>
This rev. enables the editable feature in grouped list views.
Part of task 1915702
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Before this commit, there were a crash if you tried to add an optionnal
product in a new sale order without saving it.
Apply same logic as in the ListRenderer: buttons with type="object" are
disabled for no saved yet records, as calling the python method with no
id would make no sense.
To avoid to expose this logic inside all Kanban views, we define a
specific KanbanRecord Class for the One2many case.
This could be refactored to prevent from duplicating this logic in list
and kanban views.
Original Task ID: 1945006
closesodoo/odoo#31695
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Let's assume a many2one field with a lot of possible values. The
user clicks on 'Search More...'. In the opened dialog, only 160
records are available (their ids have been obtained with a
name_search, with the optional text the user could have typed in
the many2one input).
Before 4cd379cf, that extra domain on ids was removed automatically
as soon as the user interacted with the search view in the dialog.
This was especially useful when there were more than 160 records.
However, this was rather an happy coincidence than a designed
feature.
From 4cd379cf, the ids selection was added to the initial domain
of the list, so they couldn't be removed from the domain
afterwards. The user was thus stucked with its preselected 160
records.
This rev. doesn't restore the former behavior, but rather improves
the current one, as follows:
- when there is no text in the many2one input (i.e. no value to
filter on), we bypass the name_search, s.t. all records are
available in the dialog
- when there is some text in the input, we perform a name_search (as
before) to get a list of record ids, and we add a special filter
to the search view in the dialog (the filter on those ids), s.t.
the user can remove it if he wants to access the remaining records.
- finally, the limit is now set to 320, to mitigate the problem
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31232
Before this rev., the context specified on an x2many fields (in the
arch) wasn't fully propagated to the subrecords. This means that it
couldn't be used, e.g., in the template of the sub kanban view (see
parent commit).
PR: #30881
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
The file relation_fields_tests.js was a huge 12K lines files for which some editors have a
hard time managing.
We have split it in 4 files to be more managable and removed remove unused data
and import.
closesodoo/odoo#28561
* barcodes, calendar, partner_autocomplete, web_settings_dashboard
Make the notification system better, using bootstrap toast component,
and make it available in the frontend.
The toast component allowed to remove some JS code and made the
component customizable by themes but it had to be reviewed/fixed to make
it functional (maybe bootstrap will review its work in next versions).
This work should still be improved because there are still too many
ways (deprecated and not deprecated) to instantiate toasts in the
backend. The goal here was however to make the toasts more modern and
make them available in the frontend.
This work is needed for some tasks. @kig-odoo and @fja-odoo made a
pre-work to instantiate toasts in the frontend for their respective
tasks. This commit unifies the system.
Part of https://github.com/odoo/odoo/pull/32793
task-1970731
closesodoo/odoo#32793
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This widget was exactly the same as a `one2many` and was kept for backward
compatibility reasons. It can be safely removed in master.
Related to task 1918327
With this rev., the resequencing feature (with drag and drop) that
was already available in list views is now available also in kanban
views having a field with widget="handle". This works for main as
well as x2many kanban views.
Some code handling the resequencing has been moved from the list
components (controller and renderer) to the basic ones, so that the
logic is shared between list and kanban.
Task 1902808
closesodoo/odoo#28581
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Martin Trigaux