Due to o_kanban_mobile class which adds text-overflow to all span tag
overflow: hidden is applied on activities. To avoid this overflow issue
we have to use overflow: inherit property.
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)
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
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)
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.
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
Atul Patel