Before this commit, when you clicked on the dropdown, the action
was executed but the dropdown wasn't closed.
This issue was very annoying on mobile because the dropdown is in fullscreen
and we couldn't see the result of the action.
Now, we removed the "stopPropagation" which stops the bootstrap event
to close this dropdown.
The FieldMany2ManyTagsEmail requires that the records in the
relation have an email address set. However, it didn't take into
account the changes that might have been done on the field's
value (i.e. the check wasn't applied on subrecords that just had
been added to the relation).
The field 'display_name' is automatically added to the list of
fields to fetch when fetching a record. Before this rev., its
value was also sent alongside the fields in the view for onchange
RPCs. It shouldn't: only the fields in the view should be sent.
It produced a weird bug in the res.partner form view: open a
contact (company), add a sub-contact, save -> the display_name of
the contact was then '' (and 'Contacts' was displayed in the
breadcrumbs instead of the display_name of the opened contact).
This is because 'display_name' was sent to the onchange, which
returned '' as value (because of another bug python side). So as
it's value changed, when saving, the new display_name was sent to
the server (even if this field was actually readonly).
Before this rev., we also always fetched 'display_name' when
fetching list of records (read or search_read). This wasn't a bug
per se, but it might be a computed field, and it isn't necessary,
so we stop fetching it in that case if it isn't in the view (as
it was done in saas-15, before the new views).
The problem occurred in form view, in edit mode, when the user
did some changes in the form, and then clicked on 'Log or schedule
an activity'. When validating the activity, the fields mail_activity
and mail_thread were reloaded but all changes were discarded in the
process.
This rev. ensures to reload the requested field without discarding
the changes.
Some one2many fields are called with a many2many widget to unlink
records instead of delete them. But this behavior was modified with the
new views and the records were deleted anyway.
In this commit, we restore the previous behavior, and create a FORGET
command in basic model
to do that. Note that the widget='many2many' is a hack, and a better way
to accomplish this is to use a new custom option. But this would be a
fix for master (PR #18413)
In the chat, there is an indication of when a message was sent, This indication gets updated as time passes. When the last one in the conversation is updated to an indication that takes more space (e.g. from 'now' to 'a minute ago'), the text below is pushed lower (as expected) but the chatter does not scroll down. As a result, we do not see new messages, unless manually scrolling down.
(PR #17469)
This commit introduces the 'rainbowification' feature to the web client
(and to some affected addons). This feature is essentially a way to
display a nice friendly message when some business event happens. For
example, a encouraging message is displayed when the user clear her/his
inbox, or when a salesman closes a deal.
The mechanism currently only displays a 'rainbowman', but could be
extended later to add other kind of animation.
There are a few different ways to display a 'rainbowman':
- any JS code can simply trigger_up an event ('show_effect') with some
options: for example
this.trigger_up('show_effect', {
type: 'rainbow_man',
fadeout: 'no',
message: $done,
click_close: false,
});
- an action returned by the server can have an 'effect' key, with some
options
- the do_execute_action method accepts a 'effect' option. This is
useful when one wants to specify a rainbow on an action button in a
form view
Joint work with: dbh <dbh@odoo.com>, ged <ged@odoo.com>
When a chatter is created, appended, and destroyed before being ready,
bad things could happen. This is because the code in start/other
deferred was executed regardless if the widget was still alive. And,
some mechanisms, such as _getBus, depends on the event system. If the
widget is destroyed, it will be remove from the component tree and such
functions will then return undefined.
To protect agains those issues, we simply make sure that the deferred
are only resolved when the widget is still alive.
This widget hasn't been rewritten with the new views.
The purpose of this widget is to open a popup for each invalid partners
(without email) in a many2many to fill the email. If the email is not set, the
partner will not appear in the tags and its id will not be sent (which should
not be the role of a widget but that's the way it is).
This commit improves the use of activities through various applications
by adding a counter of activities displaying next activities grouped by
application. For each application activities are divided into late, today
and future activities in order to achieve a better management.
This commit also merges Inbox and Messaging icons in topbar to keep only
one displaying All / Chat / Channels messages.
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".
This caused issue when fetching and posting message with the composer.
opw-744405
closes#17179
Before this commit, expanding a chat window would open the discuss application, which means that the current navigation state (breadcrumbs) is lost. With this commit, it simply opens a new action in the breadcrumb, and does not lose the current action. (PR 16725, closes task 31767)
Note that this implies that it is possible to have two discuss client actions open at once.
We add the o_touch_device css class to the body (it was done in enterprise only), and various other small changes to make sure that the action buttons (in discuss, next to the message title) are always visible (not only on hover) when we are on a touch device. (pr (#15459, closes task 31208)
Caused by a stupid programming error.
Also refactor a bit the code that performs mention RPCs (that are
throttled) to allow to override the throttling value for the tests.
Purpose is to be able to reload the view after posting a
message using the chatter. Reason behind that move is that
records can be updated after processing message_post and
this is the easiest solution to enable the reload feature
without having an event-based chatter.
Somewhere in the new views refactoring, between file splitting and rpc
engine quadruple refactoring, a deferred was lost. Due to this chatter
does not have correct information about message recipients.
This commit fixes it by putting the deferred back.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
Before this rev., if concurrent calls to 'read_follower' were
performed, it might happen that the read followers appearead twice
in the follower dropdown.
This was for example the case when validating an invoice: the
customer was listed twice as follower.
Note: in this particular case, the record shouldn't be reloaded
twice: this is another bug to adress.
Critical improvement,
`:)` was making a laughing guy that could be considered as mockery.
This smiley is way more friendly and should improve support feedback by at
least an order of magnitude better, maybe two.
Closes#16672
When the user changes the filters in the search view, this one
triggers up an event to notify its environment that its state
changed. This came with the new views, as before the search view
triggered an event on itself (i.e. used 'trigger' instead of
'trigger_up'). At some point, 'trigger' will be deprecated and
'trigger_up' will be used instead, everywhere.
The code in mail hasn't been updated accordingly, so the thread
wasn't updated when the user changed the filters.
When a user opens a record in a form view, the chatter is
displayed. Then, if he clicks on 'Create', the chatter is removed
from the DOM (there is no chatter in create mode). After saving
the newly created record, the chatter is displayed again, but the
same widget's instance is kept.
However, when being removed from the DOM, the event handlers bound
on elements of the chatter (e.g. 'New Message', 'Log a Note'...
buttons) are automatically unbound.
So before this rev., the buttons didn't work anymore once the form
view had switched to create mode. In this commit, we detach the
chatter's $el before updating the view, so that its handlers aren't
unbound when the old content is replaced by the new one.
Activities now have recommended next activities. Based on next activities
configured on activity types, it allows to implement light workflows
using next activities feature.
This feature was removed when refactoring crm activities to generic
activities. People asking to remove it were visibly wrong and it is
now implemented back as it was in v10.
Indeed when having a lot of available channels searchbox is displayed
quite low in the screen. This is annoying. This commit improves that
behavior by putting the searchbox above channels.
Tejas Shahu