Different templates were defined for graph, pivot and cohort views
for the no content helper. Those templates were similar (only the
message sometimes slighlty changed). This rev. creates one generic
template used by those three views.
closesodoo/odoo#34916
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
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>
Since commit 9fbb4fb, the `title` attribute is added
to list views `<td>`. The title value is given
by field utils formatting methods, according to the
field type. However, for boolean fields, the formatting
method does not return a string but a jquery element
(unless `forceString: true` is given as an option).
Hence, the displayed title is `[Object object]`.
After this commit, boolean fields do not have any title.
closesodoo/odoo#34657
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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.
The rendering of field widgets is asynchronous (as it returns a
native Promise). However, the '_renderFieldWidget' method of basic
renderers is sync, and returns a fake div that will be replaced by
the widget'$el afterwards.
The form renderer sometimes needs to add classNames on the rendered
nodes (e.g. each child of an outer group as class 'o_group_col_x').
To handle this, once the field widget is ready, we copied all
attributes of the fake node to the widget's node. Unfortunately, we
were erasing the attr value (e.g. className) by the new one. As a
consequence, the className defined in the widget were lost. This
could be observed for the 'note' field in 'sale.order'.
As this was only necessary for classNames, this rev. only retrieves
the class attribute of the fake node, and adds it to the classNames
of the widget's $el.
closesodoo/odoo#34528
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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
Let's assume an editable list with a row containing only readonly
fields. Before this rev., if the user clicked on this row and then
pressed TAB, it crashed. The crash occurred in historical code that
now seems to be useless, so we simply removed it.
closesodoo/odoo#34696
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
Rev. ee44d23 fixed a usability issue: when a doAction is performed
from a dialog, it automatically closes the dialog (as the action is
rendered in the background, behind the dialog).
However, it also closes dialogs when the action has target='new',
i.e. when it also opens in a dialog, which is not strictly
necessary in this case.
This is problematic in mobile for the product configurator widget:
in the sale.order form view, the order_line field is displayed as a
kanban, and in its form view, the product_(template_)id field has
widget product_configurator. When a value is set, it performs a
doAction (target="new") to configure the product. The widget listens
to the dialog's 'closed' event to update itself. However, with what
is done in ee44d23, the x2many form dialog is closed by the DoAction,
so the flow doesn't work.
This rev. reverts the attempt done in ee44d23, and does something a
bit more brutal: as soon as an action is pushed in target 'current'
(in the main part of the interface), all dialogs are automatically
closed.
closesodoo/odoo#34678
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Add a new behavior to numeric fields, possibility to enter value manually or to use a simple arithmetic expression that will be evaluated.
Example: =20+3*2
In order for the computation of the arithmetic expression to be done, the value needs to starts with = and then an expression can be entered. We only support the basics mathematical operations + - * / ( ) ^
User locale and digits separator are taken into account. If the value entered can't be evaluated to a numeric, the field will be displayed in error.
closesodoo/odoo#34538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: when textarea is on second tab of notebook and it has long
value then autoresize can not compute actual height of the textarea as it is in
second tab and has display: none property, it is not resized until focus comes
on it
After this commit: call DOM_updated event on notebook tab change, DOM_updated
event will call resize method again, so when tab changes resize is called and as
textarea is visible now, proper height is calculated and assigned to textarea.
task-2007558
closesodoo/odoo#34503
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
In a list/kanban view when applying a default_order on the view, it does not
work with favourite filter
Before this commit,
1) The default_order was not applied to the view when favourite filter is
applied
2) when default_order applied, Click on an element of the list/kanban and
then go back to the list/kanban with the breadcrumbs, default_order has been
changed.
This is because the ```_getOrderedBy ``` returns [] when favourite filter is
applied and it does not have sort value, added check if favourite has orderedBy
and has length then and only then pass orderedBy else pass undefined
After this commit,
1) default_order will be applied to the view
2) default_order will not be changed when going back through breadcrumbs
task-1922576
closesodoo/odoo#34001
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When e61639723d was forward-ported, there was an adapatation in 12.3
version with bbc8c9fc2 so the test pass (because of another issue where
if a line is moved after the draft line, the code tried to discard the
moved line and not the draft line).
The same adaptation is necessary in saas-12.4 but since the code changed
amply, the test was temporarily just skipped (in 83d0eaedc7).
With this changeset, the adaptation is forward-ported from saas-12.3 to
saas-12.4 and the test is re-enabled.
opw-1966589
closes#34277
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In case a many2one field (let us say 'foo') is used
simultaneously as a groupby and a measure in the pivot view,
the values returned by a read_group for that many2one are of
the form [id, label] and the aggregated values (always 1) are
missing in the read_group results (datapoints).
Thus typically, a datapoint is of the form
{'foo': [1, 'Bar'], '__count': 4, ...}
and does not contain information on the 'foo:count_distinct'
value (this is a read_group bug).
As a consequence, a special processing of the read_group
datapoints is done in the pivot model to handle that
situation and the value for 'foo:count_distinct' is infered
correctly to be 1.
In the pivot comparison mode, datapoints comming from the
period and the comparison period (data and comparisonData
sets) are identified if they have same values for the groupby
fields and the measure values become small objects containing
information on the the measure values for data and for
comparisonData and on the related variation.
Thus
{foo: [1, 'Bar'], __count: 4, ...}
from data and
{foo: [1, 'Bar'], __count: 3, ...}
from comparisonData should become a single datapoint
{
foo: [1, 'Bar'],
__count: {
data: 4,
comparisonData: 3,
variation: {
magnitude: +33 (%)
}
}
fooAggregate: {
data: 1,
comparisonData: 1,
variation: {
magnitude: 0 (%)
}
}
It turns out that the code responsible for merging the data
and comparison datapoints made a mistake by mixing the keys
'foo' and 'fooAggregate', with the consequence that the
variations were not correctly computed in the situation
described above.
This is fixed in this commit.
closesodoo/odoo#33118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After a recent reorganization of the web client's components tree, the
class 'o_enable_linking' was added on the wrong element. This made the
css rule responsible of the highlighting of the clickable pivot cells
impossible to satisfy.
This commit fixes the issue by adding the class directly in the template
'PivotView'.
Additionally, this commit also makes visually clear when a field
selection menu-items is disabled (because it is already used) using
a 'not-allowed' cursor (which was removed in bs4). It is now again
possible to open a list view by clicking on a cell with zero value
(like in Odoo 11).
task-1916889
closesodoo/odoo#34165
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this commit, one could activate the two checkboxes "use by default", and "share for all users"
After this commit, only one out of the two can be checked
OPW 2010458
closesodoo/odoo#34167
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The search buttons visibility is saved in the local storage. Rev.
6448420 changed the API of the LocalStorage servive (by JSON
parsing the values), and didn't adapt the calls done for the
search buttons.
Closes#33833closesodoo/odoo#34206
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this commit, the test `list: edit view menu item` would sometimes crash
as now the debug manager loads its templates with an `xmlDependencies` where it
was not the case before (included in base.xml), see 73327db065.
Now in 12.3, when the a editable list view is grouped, the "Create"
button is no longer shown as was the case before (when it would open the
form view when clicked).
In 12.3 when lines are resequenced, the position of the current line
does not take into account that it could have been changed (because of
drag and dropping a line before or after).
opw-1966589
closes#33878
When uploading a file to a binary file, then clicking on the
"clear" button, then reuploading the same file...
Before this commit:
The actual input of the field was only changed on user input.
This means that the "clear" action didn't reset the actual value
of the input, and the browser's default behaviour when getting
the same path twice is not to change anything. In the use case,
you couldn't upload the same file until you uploaded another one.
After this commit:
The "clear" action now also clears the value, allowing reuploading
the same file over again.
closesodoo/odoo#33843
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865closesodoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Before this commit, both config and session were aliases to odoo.debug.
Now, config.isDebug() should be call, with possibility to pass a parameter to
check if we are in a specific debug mode such as 'tests' or 'assets'.
task-1934445
Coming with https://github.com/odoo/enterprise/pull/4281
Closes https://github.com/odoo/odoo/pull/33213
Jigar Patel