The point of this warning is to help a view developer realize that
his view is not loaded at all. However, console 'error' and 'warn'
are observed by the runbot clickall tour as meaningful errors
regarding a build resulting status. It makes sense, but it is an
issue for community modules which have a gantt view that only
exists in Enterprise. We don't want to create a bridge module
for each and every module which uses a view that only exists in
Enterprise, so we need to live with this warning. Since its
purpose is for developers only, they can read the log and notice
the error even if we use console.log rather than console.error,
and that will not alter the result of the runbot clickall tour.
closesodoo/odoo#33814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Subpixels computation is different accross browsers and platforms as no
rounding rule is specified by HTML5. Difference in this computation
breaks one of the editable list tests on Chrome and Firefox on MacOS.
With this rev., it is now possible to navigate with arrows in list
views (except when editing, as in this case hitting the arrows moves
the cursor in the input/textarea), and to expand/collapse groups
with keyboard navigation.
Part of task 1915702
This error is there to help developpers realize their view has not
been loaded due to an error.
However, we have cases where we define actions containing views
that only exist in Enterprise to avoid creating an entire bridge
module just to add one view to an action.
The error was triggered in this case which resulted in a red build
for the click all runbot test, even though this was not really a
true error, as it was intended.
This commit changes the error to only appear in debug=assets such
that it will no longer put the click all runbot tour red while
still providing help for the developper trying to debug his view
since he will need to be in debug=assets to debug his view anyway.
closesodoo/odoo#31884
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The table edition feature of pos_restaurant was using an old lib
that was never updated to newer versions of jQuery by its author.
For unknown reason, this library went unnoticed when we updated our
codebase to jQuery 3.
Since this library is impossible to update per se, I decided to
remove it entirely and replace it by calls to jQuery.ui.
However, the point of this lib was to handle touch events, which
jQuery.ui does not. For this, this commit introduces a new
library which translates touch events to their click counterparts.
Tested on:
- Chrome (Windows, MacOS, Linux, Android, iOS)
- Firefox (Windows, MacOS, Linux, Android, iOS)
- Safari (MacOS, iOS)
- Edge (Windows, iOS)
- IE11 (Windows)
- Samsung Internet (Android)
closesodoo/odoo#31719
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Those tests were skipped because they were failing
non-deterministically.
This commit aims to make them deterministic by putting back some
guard promises that were lost during the jquery update adaptation.
This commit also fixes a lingering issue with one of the asserts.
We observed that sometimes, the "alt" and "title" attributes where
both present on the element but displayed in different order in
the string returned by wysiwyg.getValue(). This is because there
is no set order in the attribute returned by jQuery.html().
Because of that, I replaced the simple sring test by a thorough
manual comparison of the result that is expected to be equivalent.
closesodoo/odoo#31671
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Depending on the scale, the number of units to add to today to
compute the default period. Examples: An offset of +1 in default_scale
week will open the gantt view for next week, and an offset of -2 in
default_scale month will open the gantt view of 2 months ago.
The webclient doesn't handle a non-existing view as the default
view. However, it must handle it correctly if it is not the
default one since it does it for mrp.production already.
closesodoo/odoo#31161
- fix statusbar overflowing on the right and triggering a scrollbar
- fix background of the trash icon of the editable list remove
button which was white rather transparent
- fix cursor that was not properly displayed as pointer when on
top of the trash icon, while it properly transformed in the td
closesodoo/odoo#27806
There used to be no processing done at all when loading the client
from an url missing a menu_id and from which the menu could not
be inferred from the action_id. This resulted in the app name
button in the menu being empty but still present and not bound to
any action. Clicking on it triggered a traceback.
This commit stops ignoring the case when the menu cannot be
inferred from the action and hides the entire menu and submenus
for this particular action. They will be restored when entering
an action from which a proper menu can be inferred.
closesodoo/odoo#27791
Browsers add a 1px padding to inputs but they don't do it for the
select elements, which makes them unaligned.
Tested under Chrome 68, Firefox 61 and Safari 11 on MacOS 10.13.6.
It used to work by chance with Bootstrap 3, but since we are now
using Bootstrap 4, the fake good appearance collapsed, revealing
the awful structure it used to have.
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.
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.
The o_row class mechanism is supposed to be used to put another
element next to a field, like a button for example. However,
in the case of phone and email field, the o_text_overflow hack
gets in the way.
The problem that o_text_overflow is trying to solve is when you
have a long email, the table used to display the form view fields
tends to use very long cells (td) so it can display the whole email
address. This behavior completely breaks the form view, even though
the email address is clearly set to wrap in css. The o_text_overflow
class is a hack that forces the table to think that the email is
small, then defaulting to the width 50% css rules. If the email is
too long, it is correctly wrapped inside the cell, without breaking
the form view layout.
However, when we need to add a button next to those fields, this
hack gets in the way of the o_row class css rules, completely
wrecking it. We looked for a fix with qsm-odoo for hours but were
unable to find one that did not require a complete rewrite of the
form view css rules. In the end, we decided to remove the hack from
the phone field and keep it on the email field, as we think it is
less common to have a very long phone number than to have a very
long email.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Such buttons are not going to work on records that actually do not
exist yet. The behavior is now the same as in saas-15.
Steps to reproduce the bug:
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- Click on the little square with a + in the m2m list view, the
server will crash in the ensure_one of the function called by
the button since there is no record to run it on.
Previously, we did not handle the case where the result of the m2m
default get was a new record. In this case, we can't just send a
replace all command giving the ids since the new record has no id.
We decided to keep the replace all command even when it is empty
to stay consistent with the o2m implementation, even though saas-15
did not behave like that.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the id given to the onchange is a virtual one,
rather than a create which would not include an id.
Previously, it used to create a virtual datapoint even though there was
no change on this field. If the field was a many2one, this datapoint
triggered a name_get call afterwards, but giving the virtual id of
the datapoint since there is no real record. The solution is to avoid
creating a virtual datapoint when it is not needed at all, thus fixing
the wrong name_get call.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the web client tries to fetch the name_get of
this datapoint even though the record does not exist.
Unfortunately, ed60339 is incompatible with ebd1721 since
we once again do not send the values of readonly fields.
This is a partial revert of commit ed60339.
When I did efd15852, I accidentally undid d20074c5. That commit
wanted to filter out unwanted values from the action context, but
it was too violent, as it was discarding the action context. (See
bug described in efd15852)
My original commit aimed at avoiding the filtering of the action
context by having it devoid of unwanted values altogether. The
idea was "if this is an action button, we don't want the element
context". However, the default behavior of the _getContext function
was to add the element context. There were options to force to add
the element context despite being in a case where it should not be
added, but we needed the opposite: do not add the element context.
We used "additionalContext" in this fashion, the idea was: "if I
give you specific context values, don't polute it with the element
context". This was efd15852.
However, not all actions have context defined explicitely in their
definition. In this case, since additionalContext was undefined,
the element context was added again, despite our will not to add
it for actions. We solved this by simply always giving an
additionalContext to getContext, providing an empty one if needed.
To reproduce this bug (which is the same as efd15852):
- Go to Manufacturing
- Click on menu Master Data then Products
- Open a product
- Click on the "Bills of Materials" stat button
- Click on create
- The create crashes because of the "default_type" context key
that is erroneously passed from the "Products" action to the
"Bills of Materials" stat button action.
In previous versions, readonly used to prevent sending the values
of the fields to the server. However, it was not working properly
for fields which have their own sub-arch in the view, as the value
used to be sent regardless of the readonly value.
In the new views, the readonly modifier is never overlooked, which
created a bug in the stock_picking_return wizard which was not
able to return products received from a po anymore. Basically the
value of the product_id field was not sent so the create crashed.
This commit introduces a new "force_save" modifier which is used
to express that we want to save the value of the field even though
it is readonly from a user interface point of view.
Previously, we had to filter the context values to exclude some
erroneous values we propagated earlier.
This commit removes the earlier propagation of wrong values (the
current record context when executing an action) and thus also
removes the filtering of those values, which was actually removing
useful values from the action context.
The bug could be seen by following these steps:
- Install crm and sale
- Go to My Pipeline
- Open an opportunity which has a customer set
- Click on "New Quotation" action button
- See that the customer is not set on the new quotation, it should
be set by the default_partner_id value in the action context
Since formatBoolean returns a jQuery object, boolean fields were
displayed as [Object object] in calendar view.
This is a fix for stable version. The real fix would be to get rid
of the jQuery object returned by formatBoolean but the change is
not trivial.
The record data given to fullCalendar to use in the renderEvent
function was not parsed like it is in basic model for example.
As a result, date(time) fields were string rather than moment
objects, which was triggering the crash that started this commit.
Previously, enabling some filters created a domain of which events
to display, but disabling all filters resulted in a domain of []
which, instead of showing no events at all, actually showed all events.
In saas-15, when an event had more than 3 attendees, it used to
show a '+' at the left of the avatars. This behavior was lost in
saas-16 where it became 'display 5 avatars max and that's it'.
This commit brings back the behavior of saas-15 and improves it
such that the '+' sign displays the number of additional attendees
whose avatars are not shown and displays it on the right.
Example for 7 attendees, '[]' representing an avatar:
saas-15: +[][][]
saas-16 before: [][][][][]
saas-16 now: [][][]+4
The previous code loading the tooltip data was sending a null value
to read as id, which resulted in an access error. This behavior was
not observable in the tests because of b8c1571 which was meant to
allow giving inexistant ids to mockRead but also ended up accepting
falsy values, which was not true to the actual server.
In addition, the title of the column was wrong for unset m2o, it
displayed false, the value of the field when unset, rather than
the default "Undefined" title.
When I introduced this line in 374295b, I was working on the form
view and didn't realize I would be breaking the editable list view.
The _setMode function only updates the buttons when given the id of
a record. Since I was working on a form view at the time, I didn't
need to give a recordID to make it work since the default ID of a
form view is the id of the record itself. However, in editable list
view, the id of the view is a list of ids, so the buttons would not
be updated in this case.
When the show_address option is enabled, the display_name of a
partner becomes a newline concatenated version of his name and his
address, so the internal value of the widget is this conglomerate.
However, if one uses a keypress that does not change the value of
the input in edit mode, say ESC for example, the keyup handler of
this widget will compare the value in the input with its internal
value. If the internal value is still the conglomerate, which is
the case if the user hasn't changed the input content since
switching in edit mode, we need to trim it to compare it to the
actual input value, which is the "standard" display_name, ignoring
the magic show_address feature which is only used in readonly.
The mock server had to be modified in order to test this behavior
since it used to throw an error for invalid ids, while the actual
server just ignores it and continues forth with the other ids.
Previously, the button was completely invisible when no icon
was given, which is a regression from saas-15 where the string
attribute is used to write the button label.
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
Otherwise some changes can create rpc errors that are silently caught
and never seen as long as, out of (un)luck, the end result is the same.
Tests which need to create a server error can just simulate it using
the mockRPC mechanism.
Previously, it used to reload its data when the user clicked
multiple times on save, even though there were only changed
fields during the first initial save, all the other queued
ones have no changes at all and, as such, should not trigger
additional reloads.
Previously, it was possible to click multiple times on stat
buttons while still waiting for the result of a previous button
click. This could end up with the web client in strange states
or, worse, lead to tracebacks. Because of this, we decided to
disable the buttons once one of them is clicked and restore
them afterwards.
By doing this, we encovered a place in the code where a failed
deferred would not be properly forwarded back to the caller,
which meant, in our case, that the buttons would not be
enabled back in case the action failed. This is now fixed.
Initial methods to fix this issue used to break the test below.
Because the label of the assertion this used to break was
contradictory with the value it was actually expecting, we
decided to fix it as well.
Previously, the buttons were not updated properly after discarding
from an editable list view. The user was stuck with "Discard" even
though there was nothing to discard anymore, and he could not create
a new record either since the "Create" button was invisible.
This was fixed by 3aad756. I originally did a different fix which
has since been rendered useless, but the tests I wrote are still
meaningful since they are testing a different case than the commit
which fixed the issue.
Previously, the string attribute of the field node was ignored
in the title of the form dialog and it always displayed the
string value of the python field definition instead, which is
a default value instead.
Additionally, I took this opportunity to add tests for other
similar dialog titles which actually worked already with the
string attribute of the field node but were not tested yet.
Previously, when a checkbox was re-rendered, it was losing focus
since it was removed and re-created. Now, if the checkbox itself
is the origin point of the re-rendering, we give the focus to the
newly re-rendered checkbox, resulting in a seamless experience
just as if the checkbox was never removed and re-rendered.
The previous code used to create its own args array
for the search_read method, replacing the one that
was originally given to it.
This lead to silent errors since positional arguments
to this function were completely ignored in the case
of search_read.
I took this commit as an opportunity to improve a
bit on the current state of these rpc helpers.
Namely, the basic args/kwargs priority is the following (top-to-bottom):
- kwargs defined in the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For read_group and search_read methods, the priority is the following:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For the /web/dataset/search_read controller, only the params kwarg is
supported, resulting in the following priority:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- positional arguments are passed as is
If both a kwargs and a positional arg is given for the same parameter,
it will be sent as is to the server which will crash with a typical
"got multiple values for keyword argument" TypeError. However, in the
MockServer however, we give priority to kwargs over args in this case.
Please note that I also chose to remove unnecessary default values so
that the ones actually used are the ones from the server, not the ones
that were duplicating those in the rpc js file.
Widgets which manipulates their dom in _renderEdit were left out
from the previous implementation since this processing was done
only once when the widget is rendered the first time. If the
widget regenerates a new input upon reset for example, then it
would lack the idForLabel.
When enterprise is installed, the rendering of these widgets on
extra small screens is different, thus breaking these tests. We
need to force the test to run on normal screens.
Also took this opportunity to refactor the code of pivot to adapt
the parts that were not up to date and remove the useless deferred
in sortRows, courtesy of aab.
The exportData function still needs reworking.
The format methods of the date/datetime type expect a momentjs date
so it can call its 'format' method. Since we were not giving it a
momentjs date, the call to 'format' was crashing.
This commit also adds the special_click property which is used to mark
a DOM element such that clicks on it will not be intercepted by the
list view.
Basically, we need this on elements which rely on bootstrap events,
since those need to bubble all the way up. If we catch them in
the list view, to open a cell or a record, then they never get to
bootstrap's level and so the widgets relying on these elements
cannot work.
We plan to remove it at some point, when we have more time to figure
out a way for the click event to reach bootstrap from inside the list
view without breaking the list view behavior itself.
The original reason why this widget was created is because sometimes,
the id is a virtual one, represented by string in the webclient. As
such, the integer widget could not render it properly since it could
not parse the integer from the string. This led to the following bug,
which in turn led to the creation of the id widget:
https://bugs.launchpad.net/openerp-web/+bug/919184
Now, virtual ids are not handled within the record data itself anymore,
making it a non-issue to render the id field in the webclient since
it is not given a value until a proper id is created. The virtual id
management is completely out of the view scope now, rendering this
widget useless.
One might need all the preparation stuff that InputField does on
its input but might need something else as its tagName and handle
the input differently.
This commit gets the input preparation code out from the rendering
part of the widget so one can render a widget the way he likes and
call _prepareInput on his input.
This is used in monetary field which requires all the feature of
InputField but with the input actually being one level deeper in
the DOM than the standard InputField.
Some fields react differently depending on the values in web.config.
For example, the phone field will display a clickable phone link if
it detects a small screen (e.g. a smartphone) but won't do it on a
bigger screen.
To be able to test fields which react differently depending on the
values in web.config, we need a way to mock it. To do that, we
modify web.config in place with the value given for the test, and
we put back the original config when the field widget is destroyed.
David Monjoie