In many2many lists, the remove record from the widget is a trash bin.
It is confusing, as people feel they are deleting it when they are
only unlinking it.
So in many2many, we propose to change the trash icon by a 'X'.
This icon appears in many2many relations and in many2many widgets:
even though hr.expense.sheet defines the expense lines as a one2many,
it uses a many2many widget, so we use a 'X' instead of the trash bin.
To avoid ambiguity, we decided to rename 'delete' to 'remove'.
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
- Set the currency rounding to 0.001 (3 digits)
- Create an account move
- Add an account move line, set an account
When switching from edit/read-only mode, the rounding switches from 2 to
3 digits.
This is because, in edit mode, the format method is the method of the
float widget. Therefore, in this case, the formatting doesn't take into
account the currency rounding.
To avoid this, we simply use a `noSymbol` flag to avoid adding the
currency symbol, while keeping the monetary rounding.
opw-800279
If a row is being edited, this row will be refocused when performing changes
(i.e. resequencing records). It can cause an issue if an onchange modifies the
record being focused.
To avoid this issue, the row is unselected before resequencing records. The row
isn't selected anymore but this behaviour wasn't expected anyway.
Resequencing records with the same sequence wasn't correctly working in the
editable list because we only care about the range between the swapped ids. In
some cases, this isn't good enough.
For example, if we have the records 1,2,3 with sequence field = 10,10,10, then,
swapping records 1 and 2 should lead to resequencing 3 with the sequence values
11,10,12 (to guarantee that the third item is after the previous 2).
Resequence now checks if the list increases or decreases without interruption
to create the subset that must be changed ; otherwise the whole list is changed.
When modifying files the a widget FieldMany2ManyBinaryMultiFiles would
not keep its metadata (currently associating attachment to [url,
allowUnlink]) up with current value.
So with an attachment added after init:
- clicking on it would error (because link is wrong)
- deleting it would unlink attachment originating from from onchange
The expected behavior is:
- being able to download attachments
- not unlinking attachment originating from onchange
and this is what this commit fixes.
opw-787746
closes#21813
Discarding a new record triggers the 'history_back' action. This makes
sense if the record was discarded from a normal form view, but not so
much when in a modal, where the expected behaviour is to close the
dialog.
This commit overrides the function in the action manager which handles
the switch to the previous view. It checks whether a dialog window is
open, in which case it simply closes it.
note: 10.0 backport from 11.0 33aa89edcloses#20405
opw-786866
closes#21792
Before this rev., when a graph view was reloaded (e.g. by clicking
on the graph view switcher), the inital groupby was lost if it
didn't come from the searchview (i.e. if it came from the context
or from the arch). For instance, go to Sales > Reporting > Sales
(the view is grouped by 'date', and there are two groups), reload
by clicking on the graph view switcher: there is only one group
left.
The reload RPC was actually fine. What was wrong is the 'state'
object given to the renderer after the reload, as it didn't contain
the correct groupby, so the view wasn't correctly re-rendered.
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
There is a drawback in 12048bd6, if a kanban view with an
"Undefined" column (exist when a kanban view grouped on a relational
field and some record have this field unset) had a column resequenced a
traceback would happen if more than one column was displayed.
This happen because before we had a "undefined" ID for the "Undefined"
column and after 12048bd6 we get a framework unique ID which was not
managed.
note: this commit also adds `left`/`right` values in the dragAndDrop
test utility function so an element can be dropped at the right/left of
another element.
related to opw-782433
closes#21708
The kanban view uses a template which comes from the server, already
translated. Before this commit, it tried to retranslate again the
template in qweb.js, which may be a problem (in addition to the useless
work): if some english string A is translated in B (french), but B is
also a valid english string which is translated into C in french, then
we will have a wrong result.
In this commit, we simply add a flag to disable the translation process, which
should also slightly improve the kanban view rendering performance.
On a tree view:
- Add a button returning an `act_url` action; e.g.:
```
@api.multi
def open_google(self):
return {
'type': 'ir.actions.act_url',
'url': 'https://google.fr/',
'target': 'new',
}
```
- Click on a button
The action call works only once because the button is never re-enabled.
The button is actually enabled only at view rendering. Therefore, we
call `on_close` in order to reload the view.
opw-784587
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The kanban view uses a template which comes from the server, already
translated. Before this commit, it tried to retranslate again the
template in qweb.js, which may be a problem (in addition to the useless
work): if some english string A is translated in B (french), but B is
also a valid english string which is translated into C in french, then
we will have a wrong result.
In this commit, we simply add a flag to disable the translation process, which
should also slightly improve the kanban view rendering performance.
If a kanban view is grouped on a many2one, records with the field unset
are displayed in a column "Undefined" displayed first.
But the tab in mobile view doesn't respect this, so we can get:
columns: Undefined colA colB
tabs: colA colB Undefined
So we always get always on the wrong column wrong when clicking on a
tab: clicking on colB we get on colA, clicking on Undefined we get on
colB, ...
note: in this commit the "false" tab has been set to a translatable
"Undefined" name.
issue found when working on #21199
If at one time kanban column are sortable then they stay sortable for
ever even if they should not.
eg. kanban view is grouped by a many2one (sortable) then by selection
field (should not be sortable): the columns are still sortable.
issue found when working on #21199
A kanban column has two identifiers:
- db_id: framework unique identifier for the column
- id: either the record res_id (grouped on x2o) or the value
The issue is that sometimes the value may be a any string which
would be source of issue unexpected for an ID (and there was one
issue in mobile renderer).
This code change this so "id" is either the record res_id or
`undefined` value, and when used in XML we use id or fallback on db_id
when we need an identifier.
So in the XML data-id on a colum is always either the ID of the record
the group is based on, or the db_id in the form.
opw-782433
closes#21199
Before this commit, when grouping a kanban by date with a modifier
e.g. crm.lead grouped by create_date:month
A traceback was thrown on the python side bacause create_date:month was literally not a field
After this commit, the progress bar in that situation displays well,
at the price of copying bits of the read_group infrastructure
OPW 785021
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The bug is also present in enterprise but the required style of
enterprise makes the bug invisible. The bug has also been naturally
fixed in 11.0 thanks to the views and design refactoring.
Thanks @auyeung112002 for the original fix.
The 'main_flow_tour' noticed an error that we
had already corrected for the input fields.
See here: @a71f2237
In fact the same error can occur in the many2one fields
for the exact same reason.
It's why the 'main_flow_tour' crashed at the following step:
".ui-menu-item > a:contains('the_flow.customer')"
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
Christophe Simonis