Fp request: In the user preferences menu, remove "About Us" and put the version number in the Settings dashboard somewhere, as well as the link to switch to developer mode. Odoo is not a desktop application anymore.
For the need of the next commit, we have to know when making a request from an RPC call in which debug mode we are. Previously, the value was always 'true' if we were in debug mode. Now it will return 'true' if we are in simple debug mode and 'assets' if we are in the other one. (this is the current behavior for the simple WebRequest).
Why do we need to know that? When loading the settings dashboard, an rpc request to /web/dataset/call_kw to load the view is accessing the odoo.debug @property method. This value is used in the template to decide which buttons to display to activate or deactivate the debug mode.
When you backup 3 dbs with the database manager, you had 3 times the warning.
Underscore is not loaded, so _.once not available.
This commit closes#13173
This is a following of revision
ab8a93c852
This revision solves a new case:
when quickly performing a second search
after one which has not been resolved yet in a kanban view, and the second
search is resolved before the first, it was not possible to load the form
by clicking the card of the kanban, it leaded to a
`Could not find id in dataset` web client error
This was because the ids of the dataset were altered with
the ids of the first search (the one that lasted longer), while
the records displayed were the ones of the second search
(the one that finished first)
opw-682362
Fp request: In the user preferences menu, remove "About Us" and put the version
number in the Settings dashboard somewhere, as well as the link to switch to
developer mode. Odoo is not a desktop application anymore.
When double-clicking on the statusbar widget, two calls to write are
performed. This can cause unwanted behavior, and when the `write` method
takes a lot of time to process, it's not possible to prevent it
server-side.
Courtesy of @gurneyalex and @aab-odoo
Closes#13135
opw-686025
Before rendering the radio button, the radio button must be unchecked
to ensure to take the last value checked.
Step to reproduce:
-From main menu, click on 'Contacts'
-Click on 'Create'
-Select 'Company' value on company_type field
-Save or not the contact
-Return in the main contact view (click on breadcrumbs)
-Click on 'Create'
Bug:
The default value on company_type field is 'Company'
but the fields that should be hidden are visible (example : parent_id field)
After the fix:
The value of company_type field is 'individual'
opw:684847
After commit 6739e10, we have two widgets to be able to choose
two dates according to the operator (e.g. between).
So, the second widget is not always available.
'toString' generates the string to put in the facet and should
convert the second date only if the second widget exists.
Before this commit, it was not possible to make search filters with
only one date because we try to get value of widget that does not exist.
An issue occurs in the following use case:
- Create an automated action
- Choose a Related Document Model
- Select records to filter (click on "Select Records")
- Do not save, but cancel instead
- Create an automated action once again
The filter domain keeps the same value than previously, forcing the user
to refresh the page to get rid of it.
opw-683214
When positioning an element in an editable list view, that element is
temporarily forced to display: block thanks to the class o_temp_visible
The rule is written in LESS thanks to:
.o_list_editable .o_temp_visible { display: block!important; }
which is ok for normal invisible form fields because it is written as
.o_form_view .o_form_invisible { display: none!important; }
which has the same priority but is defined before the o_temp_visible
rule, so the display is properly forced to block.
However, for some reason, there also is the rule:
.modal .modal-dialog .o_form_invisible { display: none!important; }
which has a higher priority than the o_temp_visible rule.
This is why appearing invisible fields in editable list view in modals
are at a wrong position.
The solution introduced by this commit is the safest: adding a new
rule to force display block!important on the selector:
.o_list_editable .o_temp_visible.o_form_invisible
This tries to be the smallest patch possible in order to avoid triggering
another display issues, so we only patch in the ms-hight-contrast section
which only applies on ie 10/11.
* The view-manager weren't displayed correctly; they didn't fit 100% of
the screen width. This is fixed by explicitely seting the top, right,
left, bottom attributes.
* The modals content were not displayed. This was due to 2 issues:
* The rule that we patch in the first point set the position of
`oe-view-manager` as absolute with an importang flag. Because of
this important, the rule that reset the position of the
`oe-view-manager` as static in modals.less was not honored. So
we also patch this rule with an important flag inside the same
file (so that all the fixes related to ie10/11 are in the same
place).
* Now that the modals are displayed, they do not fit 100% of the
screen. It's because the `max-height: 100%` of `.modal-content`
set in modals.less does not work in ie10/11, due to some bug
with the flex displays. We set the height to 450px so that the
modals are kind of correctly displayed on a 1366x768 screen
(their content are still scrollable).
related to rev 1ccd87a037closes#12929
Commit 977db823c7 refactored the web module so that it gathers
common features of community and enterprise. The problem is that the
web.webclient_bootstrap template content lost its groups attributes.
This had the effect to make the client crash when accessing the
template for calendar invitation for example, as the template was
trying to render menus without menu data.
The main content of the web client was set to grow/shrink so that it
fills the window (thanks to flex). However, to be able to shrink as
much as necessary the min-height needs to be forced to 0.
Without this fix, the web client was overflowing on the bottom of the
page, making impossible to access some menu items.
This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).
Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:
.modal
/ \
... (new S.T.) ... (new S.T.)
/ \
... (new S.T.) ... (new S.T.)
/
.o_list_editable (new S.T.)
/ \
.o_form_view (new S.T.) .table-responsive (new S.T.)
/ | \ \
input input input table (new S.T.)
This explain why the input are not visible: actually, they are displayed
behind the table. In this case the document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004 [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.
The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.
The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.
With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.
This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.
opw 683169
cherry-pick of odoo/enterprise@35f285e50a
[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c7
and never forward-ported to saas-10.
When the webclient calls do_action from the app_switcher, it toggles it when
the returned deferred is resolved.
The logout client action didn't return anything, so when logging out from the
app switcher, the webclient directly toggled the app_switcher and displayed
the last opened action if any, and a gray screen otherwise.
This commit makes the client action return a deferred which is never resolved,
so the app_switcher isn't toggled when logging out.
This is done in order to enable the tour service only for the
superuser. Commit 6ef1644a7b changed the meaning of `is_admin`
to achieve this but broke the fact that some features of the debug
manager are available to admin and not only to the superuser. Anyway
a `is_admin` key should mean that the user is in the admin group.
We could have checked client side that the uid is equal to 1 but
adding a `is_superuser` key is more elegant and easier to grep.
Also fix the only occurence of a uid check in the weblcient.
This reverts commit 6ef1644a7b.
The tour mechanism displays a tour if the `session.is_admin` key
is set to True. For this key to bet set to True, you need to be
in the system group.
Default options adds the system group to any created user, however as
there aren't any ir.model.access rule defined on the `web_tour.tour`
model, when you try to login as this created user, you get a traceback.
As the only way to reach a `web_tour.tour` record is to have the
superuser_id, update the `is_admin` condition accordingly.
get_formview_action and get_formview_id are methods used notably in a
redirection called from a mail controller used in notification emails.
Those methods however are defined as cr, uid, id and are interpreted
as api.one when called by a new-api style method.
With modules being converted into the new API, those methods are called
as api.one and the result is encapsulated into a list.
To avoid having to take the first element of the returned list we decided
to simplify the call chain and migrate the methods as multi methods, using
ids instead of id. Various addons have been updated accordingly. A temporary
support of ids being an int / long has been added to avoid conflict with calls
using id (for example if javascript is not updated).
The fith arguemnt of the search method in count in new API.
Passing all arguments as positional arguments will make the context passed for
the value of the `count` argument.
bbc67ec is a similar fix in 9.0
Closes#12830
Yannick Tivisse