The web modules defines a "layout" template which is only used by the
login default page. Now the backend template "web.webclient_bootstrap"
and the frontend template "website.layout" both use the "web.layout"
template as base.
Some parameters can be passed to customize the default "web.layout"
template:
- "head": content will be placed at the end of the <head> tag of the
page
- "title": to set the title of the page (the <title> tag should not be
placed "by hand")
- "x_icon": the url for the page icon
- "html_data": dictionnary whose key-value pairs will be placed as
attribute-value for the <html> tag
- "body_classname": the classname to set on the <body> tag
Note: xpath expression on the website.layout template can now only find
the #wrapwrap element and its children. An expression "//body" will not
have any result. If something has to be added in the body element but
not in the #wrapwrap element, simply change the xpath
<xpath expr="//body" position="inside"> with
<xpath expr="//div[@id='wrapwrap']" position="after">
Previously all the fields were removed when switching export type, even
if they are available in the newly selected export type. This commit
fixes that.
* display all lines and don't display the scroll bar into ace editor
* lazy read ace lib and add missing lib file
* use not minified version of ace lib
* Move ace lib from website to web
* Added ace widget for webclient
* XML mode for view text box
* Python mode for server action text box
* Removed web_ace_editor.xml, instead added template in base.xml itself
* Added widget=ace_editor in compute field of ir.model.fields
* display all lines and don't display the scroll bar into ace editor
* lazy read ace lib and add missing lib file
* use not minified version of ace lib
* Move ace lib from website to web
* Added ace widget for webclient
* XML mode for view text box
* Python mode for server action text box
* Removed web_ace_editor.xml, instead added template in base.xml itself
* Added widget=ace_editor in compute field of ir.model.fields
Since the commit odoo/odoo@36e875e which disable the second-guess from browser,
IE cannot display picture from Odoo where mimetype is wrong.
Before this commit, IE and probably other browser which one respect the header
'nosniff' don't display picture not_found and resized picutre via controller if
the original was not of type 'png'.
Eg: when we return the placholder 'not_found' if you don't have permission,
or when your resize the picture, ... we need to force the mime-type with the
new one and not keep the original mimetype.
This commit closes#13193
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 a user connect to /web/database/manager directly without the
login page before, the request don't have registry.
When the user click to backup a db, a traceback was raised:
return request.registry['ir.http'].content_disposition(filename)
TypeError: 'NoneType' object has no attribute 'getitem'
Because it was impossible to call content_diposable from ir_http
without registry.
Now content disposable has been moved in http.py and is callable from
anywhere.
This commit closes#13192
This commit closes#11583
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
qsm-odoo