Before this commit, the widget many2many_tags only loaded the first 40
records. This was difficult to see, because there were not so many views
with a lot of tags.
Before this commit, there was a bug when creating a new record which
contains a one2many with an onchange. The commands sent to the onchange
did not contain the full information.
Here is how you could reproduce the issue: install expense, go to the
expense list view, select the 2 lines, then, in the 'action' menu in the
control panel, choose 'Expense: submit to manager'. In the new expense
sheet, you could see that there were two lines in the one2many
expense_line_ids. However, these lines are empty. The reason is that
the commands sent in the onchange were 2 commands 0, with {} as data.
So, in short, the BasicModel did generate the proper commands, but with
empty data, in the specific case when we have a non empty one2many in a
default_get, then an onchange.
To solve this issue, I had to fix 2 things: the internal data struture
was wrongly updated, and the commands should be generated with all the
data, and not only the changes.
Before this commit, m2o external button was always floating outside the
m2o main DOM element, on the right. This induced problems when using the
m2o outside of views (like in Odoo Studio). Now, the m2o design is made
so that this button is inside the m2o, except in form views where we
expect the button to overflow in the tables' right paddings.
The parsing of the integers does not escape the thousands separator.
issue: Integers are currently not properly parsed. For example, create
a database in Spanish language, install product_expiry and in settings
activate Lots & Serial Numbers. Go to Products and create a new product.
Choose to track by lots and specify the use_time, life_time, etc.
When saving, all integers are set to 0
In mobile, the .o_kanban_card_content width wasn't defined.
In desktop, we don't have this issue because the .container bootstrap
element set the width.
Now, the kanban card content is correctly displayed in
the workcenter kanban view.
A bunch of features had been added to the qweb test files and qwebjs
did not pass them as features were either implemented differently or
not implemented at all:
* Fixed wonky and not cross-impl tests
- added ``not`` word replacemenet to qwebjs as I wasn't sure how to
handle that one cross-impl
* fixed t-esc/t-raw to render content *inside* the host node e.g.
span@t-esc should render as <span>{contents of esc}</span>
* added fallback to body content if t-esc/t-raw yields an empty result
* process t-att in order with t-att-* and t-attf-* rather than before
them both
* suppress attribute generation entirely in case of falsy value
Since the new views, the field parsing for m2o returns an object with
id and display_name. If the given value to parse is a string, it is
supposed that this is an ID. This was breaking the domain selector
widget which should allow strings as name-strings of m2o values.
We clear the input field when clicking 'Create and Edit' to ensure that
the field is empty if the user chooses to cancel the record creation. If
a record is indeed created, then the field value will still be updated.
When the quickreate fail and a slow create is used instead, don't
display the error that happened as is done in kanban and calendar
(following 0f7f3fc2f) quick create.
It's not possible to click on the show details button if the picking is
not saved. It's a limitation of the webclient. This commit introduces a
waring telling the user to save the form view first.
Before this commit, two variables were used to store the current
position in a list view: currentCol and currentRow. This made it
difficult to handle incremental moves (eg: tab, shift+tab) inside a
row, since we have to ignore all buttons. Previously, this was done by
converting 'currentCol' to 'currentFieldIndex', but the conversion
between the two variables was incorrect and does not appear to be
that easy to fix. As an example, it was not possible to TAB-navigate to
the last column of the components list when creating a BoM.
This commit removes all mentions of 'currentCol' and uses
'currentFieldIndex' instead, removing the need for conversions. The TAB
navigation code is simpler as a result, and should now be correct.
The sum is already used in views for
<field name="foo" sum="Total" />
Where "Total" is translatable and extracted in source terms export.
The progress bar kanban widget expect a field name (untranslatable).
Avoid to translate a field name by changing the attribute
When a record was added in a kanban thanks to the quick create, column
tooltip and column progressbar were not updating the values they showed.
Now, adding/deleting records updates the whole column as the update
operations.
Thanks to @kig-odoo for the test.
Note: to backport (partially)
When using quick create to create a kanban record, if this record was
then updated thanks to a field widget, the view crashed. This was
because it tried to update the whole column but the newly created
record was not properly attached to it in the model.
Thanks to @sja-odoo for the test.
Note: to backport (partially)
When an onchange is set on an x2many field displayed as an editable
list in a form view, and the user updates one of the subrecords,
the updated subrecord is kept in the DOM and updated, and all other
subrecords in the relation are re-rendered and re-inserted at their
correct place in the list (because the onchange might have changed
them).
Before this rev., the order of the subrecords after the edited one
was reversed.
Kanban records with 'global click' feature activated should open
the record in a form view when the corresponding card is clicked.
Before this rev., it wasn't working if the user clicked on a tag
of the kanban record, because of an unused click handler defined
on the Many2ManyTags widget (preventing the global click feature
from actually performing the global click).
This rev. removes that handler in the KanbanFieldMany2ManyTags.
This reverts commit b6ef149b as it seems that we don't want this
feature ultimately (was confusing for users trying to open the
record, but it filtered instead).
Note that opening the record by clicking on a tag still doesn't
work, but this is fixed by the next commit.
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
The one2many default get code used to meddle with basic_model's res_ids
manually, which ended up desynchronizing the data and res_ids fields
of the list representation of the one2many values.
This commit solves the issue by using the proper mechanisms of the
basic_model, that is creating a proper datapoint for those ids.
Steps to reproduce the original issue:
- Install sale_mamangement, mrp and purchase
- Create a product
- In the Inventory tab, in Routes, uncheck Buy
- Check and then uncheck back any other route than Buy
- Get a traceback because we are looking for a record with a given
res_id in the list data but since they are desynchronized, data
is empty at that point even though res_ids is not.
https://github.com/odoo/odoo/commit/36b4d78a2678806b25aaa5650b64496f9da9d205
fixes most post-onchange focus issues for x2many fields, but does not
account for "button columns" properly. More precisely, the current
widget is computed via a position index taking buttons into account in
an array that ignores them. This caused the index to be out of bounds,
resulting in a traceback. This commit fixes this issue.
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
Before this commit, pressing tab then enter was generating a traceback because
the event creation and modal deletion was done twice.
This commit adds a protection to be sure that we are doing only one event
creation.
Before this commit, error thrown by scripts injected in DOM won't return a
clean error on window.onerror.
It would open the crash_manager's show_error's dialog that wouldn't display
any informations except "Script Error." and "Traceback:".
This is because of browser's security reason: it will just give you a
'Script error.' as message and nothing else for security issue.
Now, this kind of error will show a clearer message informing that it is
probably originating from a Javascript file served from a different origin.
There is now also the possibility for developers to handle/override the
behavior when this kind of error is catch to prevent the dialog to open for
example.
Might be of use:
https://blog.sentry.io/2016/05/17/what-is-script-error.htmlhttps://stackoverflow.com/a/7778424https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/ (Search for Script Error)
The one2many default get code used to meddle with basic_model's res_ids
manually, which ended up desynchronizing the data and res_ids fields
of the list representation of the one2many values.
This commit solves the issue by using the proper mechanisms of the
basic_model, that is creating a proper datapoint for those ids.
Steps to reproduce the original issue:
- Install sale_mamangement, mrp and purchase
- Create a product
- In the Inventory tab, in Routes, uncheck Buy
- Check and then uncheck back any other route than Buy
- Get a traceback because we are looking for a record with a given
res_id in the list data but since they are desynchronized, data
is empty at that point even though res_ids is not.
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.
The wiggling effect of the edit button when clicking on the form
(hinting that to change the form you should edit it) could happen
several times.
With 85d1e76 there was also a visual deffect on the Edit button when the
wiggle happened several times, because bounce are stacked but the CSS
class was removed after the first bounce was removed.
This commit introduces a new way to hide a column in a x2m list view.
The attribute 'tree_invisible' can be add in the field attrs in the x2m
view definition. This attribute can use the 'parent' key to make a reference
to the parent record (e.g. 'parent.id').
Christophe Simonis