In some cases, the calendar view sends a trivial domain, such as
["partner_id", "not in", []]
This is clearly not really useful, and it could hurt performances in
some cases (for example, if the partner_id field is a related on a large
table, and non stored).
This is clearly not a complete fix, but it is easy, safe and does not
hurt.
The pdf viewer uses an external library to display a pdf file. This
library displays a few controls, such as a 'Download' button. However,
this button is sometimes displayed in the top bar, sometimes in the top
right dropdown menu (depending on the size of the widget).
For some unknown reason, the pdf viewer widget disabled the download button.
But this was inconsistent: the download button was only hidden when it
was in the tob bar, and not in the dropdown menu. With this commit, we
simply remove this behaviour.
Some people prefer not to be disturbed by any flashy information. In
this commit, we add an option to do just that. When the 'show_effect'
option is set to false, then the messages that would be displayed by an
effect will be displayed in a notification.
Task #37712
Co-authored-by: Mohammed Shekha <msh@openerp.com>
By default, Chrome browser will block pop-up windows which will block
all actions from type act_url with a different target than 'self' (i.e.
'_blank').
This commit adds a check when such an action is called and sends a
warning in the web client when it fails to open. This mimics the
behaviour already present for the report actions.
Due to the switch from less to scss, changes were made. Especially, the
class oe_link is now 'deprecated' and interpreted as 'btn-link'. The
previous style defined on the latter removed the padding which breaks
the style when several buttons follow each other.
This commit should fix the style while maintaining the intended behaviour,
a vertical alignment between the button and the text inside the pane.
With this commit, we introduce a better screen to manipulate the search
view in a mobile device.
Note: most of this work was initially done by suh-odoo, then was adapted
and moved to community by myself.
task 31464
Here is the story of the problem: back in 10.0, everything *seemed*
fine with button rendering except it was very messy duplicated codes.
The system was still not consistent:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> no class
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, outside the header, the system seemed to not process anything except
transforming the oe_highlight class. In the header, the btn-default was
always added, except if using the oe_highlight class. The style is fine
for those, except for .btn-default.btn-link and .btn-default.oe_link
where the link class has no effect (which is fine as header are not
supposed to contain links).
In 11.0, the new views were introduced alongside websitepocalypse. The
new system led to:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-default oe_highlight
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> oe_highlight
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, it worsened the header buttons by not processing the oe_highlight
class and adding the btn-default class in all cases. This is even
worse since in 11.0 .btn-default.btn-link do have a specific style and
thus not appear as .btn-default anymore. Those may be invisible "bugs"
though as .btn-link are not supposed to be in header and oe_highlight
is styled correctly in css. For buttons outside the header, a little
processing was added to add "btn-default" class for buttons which did
not specify a class (and oe_highlight is not processed anymore there
too).
In master, with the less2scss task, the system had to change again but
led this time to visible bugs:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
As you can see, the system is now the same for both header button and
normal buttons. The system is also better for all cases as it produce
only *one* *bootstrap* class for all cases. However, the problematic
case is the last one for header buttons: it did not receive the
btn-default class automatically. Even though this is the API for the
rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is
a problem here as fixing this would require to add the 'btn-default'
class in every view which is using this case.
While waiting for a better solution, this commit is instead forcing
the btn-default class in that header case only (so only when a class
was mentioned but it did not contain any bootstrap btn type class).
So the new system gives:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
This commit also adds tests which will prevent the system to change
again without noticing it.
Closes https://github.com/odoo/odoo/pull/24443
The cover image top and bottom margins should be the same on a kanban record.
The bottom margin on `o_attachment_image` has thus been removed as it is already
defined on `o_kanban_record_body` class, which makes a double bottom margin.
Task 54019
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
This feature has been removed in rev. odoo/odoo@e533085 but this commit
reintroduces it. It was considered as "too dangerous" for new users.
Instead of removing the feature, a confirmation request has been added to warn
the user about his potentially harmful action.
The same warning has also been added in List view when archiving records.
Task 60393
Co-authored-by: Mohammed Shekha <msh@openerp.com>
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
Since 11.0, reports could not be edited at all anymore. This is due to
the fact the editor files were refactored but the report feature is not
correctly organized since it was merged with the 'web' app. Indeed, the
'web' app is still calling files and assets of the 'web_editor' app which
is not a dependency (but it is working as 'web_editor' is auto-installed
with 'web').
opw-1826599
opw-1834971
Closes https://github.com/odoo/odoo/issues/24034
Before this commit, when uploading a file as attachment in Safari,
The file icon kept on showing 'downloading' whereas the request was successful
This was because the return from the server had a different UTF-8 norm than Safari
After this commit, it works well
OPW 1836545
closes#24307
Assume a list view with a many2many field, and a record for which
that many2many contains a single value, whose nameget returns the
empty string (which is a falsy value in JS). Before this rev., it
triggered an infinite number of namegets, and the browser crashed.
It was because the cell was re-rendered when the nameget returned,
and in the rendering of the cell, it re-performed a nameget if
the value was falsy.
opw 1838255d
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
In some situations, it could happen that the action manager had a
rejected deferred representing the creation of a view, and was blocked
from doing any other interaction with that view.
For example, imagine that a read operation crashes for record 1 on the
model res.partner. If the user is on the kanban view and click on
record 1, there will be an error dialog informing him of the error.
However, if the user clicks then on another record, nothing will happen
because the action manager is blocked (only the form view in this case).
With this commit, whenever the view creation process failed, we also
remove the rejected deferred so the action manager will be allowed to
try again.
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
Currently, the default field widget of type html is not defined in the
web addon, but in the web_editor addon. It uses the summernote library
and different assets.
The web_editor addon is defined with auto_install=true, so it is usually
not an issue. However, it could happen that there is some issue with
the web_editor asset bundles. In that case, any form view with a field
of type html will crash.
With this commit, we define a default widget of type html in the web
addon. This will render as text (so, not exactly what one might
expect), but it is still better than making the web client unusable.
Géry Debongnie