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.
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>
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
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
Now that the debug mode is stored in session, we need a clear indication that
debug mode is activated.
In backend, the 'fa-bug' is doing the trick but in frontend there is no visible
clue that debug mode is enabled.
This commit separate the debug manager code/feature so we can instanciate it in
frontend only with usefull options (such as enable assets, leave debug mode..).
Now, in frontend, people having access to the navbar (o_main_navbar) will see
the same 'fa-bug' icon with minimal options as mentioned above.
Also, in the footer, there will be another 'fa-bug' icon without any options.
It will be usefull when the navbar is not shown, typically the case for
public user, or for portal (without website installed)).
Clicking on it will simply leave debug mode as hinted in tooltip.
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
This is a first step towards lazy loading the majority of the JS: the
boot JS code should not depend on any libraries (underscore.js and
jQuery).
Even without lazy loading in mind, this would be a nice-to-have.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
This commit adds a new parameter on fields for list view and one2many.
The parameter name is "optional" and its values are "hide" or "show".
Columns of the list view which have the optional parameter set are
listed in a dropdown that can be toggled from the last cell of the
table header. The ones with optional set to "hide" are hidden by
default.
User choice is stored in local storage. If no saved parameter can be
found in local storage then the default value from the view is used.
Due to the overflow behavior of the responsive table, we were forced
to wrap the table-responsive div in yet another div. We changed the
o_list_view class on the table to o_list_table in order to reuse
the more generic o_list_view class on the top-most div. CSS rules
and selectors had to be updated according to this change.
Task-1902765
Since JS refactoring of ActionManager at 32b8cec536, the /apps/<app> controller
was not working anymore as the refactoring dropped the support of `sa` as URL
state.
closesodoo/odoo#33679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In 11.0 091c86c21 introduced the unselection of lines when line are
resequenced to solve some issue.
There seems to be a related issue in the following use case if:
- the one2many has a handle field
- the lines have same sequence (eg. adding 2 o2m lines on new record)
- there is an invalid o2m line (eg. empty line and required field)
- without blurring, a valid line is moved
then this happen:
- the sequence of lines are computed
- the invalid line is removed
- the computed sequence of lines are applied
=> this break next onchange, because we try to apply an onchange to data
that does not exist anymore (the invalid line).
With this changeset, the invalid lines are discarded before sequences
are computed so the computation is still correct before being applied.
Without the change, the added test fails with:
5. one onchange happens when lines are resequenced (expect: 3, res: 2)
7. one onchange happens when a line is added (expect: 4, res: 2)
8. onchange worked there is 2 lines (expect: 2, res: 1)
opw-1966589
closes#33591
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Yannick Tivisse