| Age | Commit message (Collapse) | Author |
|---|
|
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
|
|
Only messages as comments and email template should keep a white backround since they are not internal.
It is also enough to display fields that changed on subtypes (update message) since emails will be reworked soon and more information will be given there. The support of 'always' track can be removed. (is now considered as a simple tracked field)
The use of self.env.ref('mail.mt_comment').id add some query and the performance tests needs to be update since message_format is called by notify_by_chat. This code will be refactor later
|
|
This reverts commit 935e4f6a252ecd87d660d8433aa88fee41839fff.
|
|
Remove "always" tracking support
Change greay background logic
|
|
The `isMobile` variable was defined at the right place (`config.device`)
but was set at the wrong place (`config`).
Thank you for making me author of all the `isMobile` lines by
the way... :)
|
|
- Extract mobile specific code for the client action to a specific
file
- Massive clean of less rules
- Unify channels preview of the systray dropdown and the mobile UI
of Discuss
- Ensure to only load the last message of each channel in mobile,
as this is not used in desktop (unless the user opens the systray
menu)
- Make livechat available in Discuss mobile UI
|
|
- Brand new UI for Discuss client action (with tabs for Inbox,
chats, channels...)
- In mobile, conversations always open in Chat Windows
- Chat window UI improved (both mobile and desktop)
- Channels preview (used in the systray menu, and now in the mobile
UI of Discuss) improved
- Other minor less tweaks
|
|
*im_livechat,rating.
Emojis are now encoded in unicode characters in messages. This
allows to copy/paste messages including emojis, ensures that
emojis are properly displayed in mail interfaces (at least those
that support unicode, e.g. GMAIL, counter-example: outlook), and
allows the user to directly use emojis of its smartphone in mobile.
This commit also adds several new emojis.
PR #11095
|
|
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>
|
|
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
|
|
The RPC system was not completely satisfactory, we decided to prepare
the future and do it properly. This commit introduces the new rpc
system, which replace the previous new one. We now simply have a
method, this._rpc, which takes a dictionary of parameters. The idea is
that depending on the parameters, it is able to add correct default
value when necessary.
For situations where we don't have the this._rpc method, we can use the
rpc.query method, which takes the same arguments, but directly calls
ajax.rpc instead of triggering up some events.
|
|
The _rpc method is now the preferred method to do a rpc, so we need to
update all calls.
|
|
|
|
This commit tries to refactore the management of contexts and domains
in the webclient.
- Get rid of CompoundDomain: use standard array manipulation to
join multiple domains or use the Domain class (to be improved)
- Get rid of data.js build_domain and build_context methods
- Link this.record to the data point from the basic model for all
fields (not only relational fields)
- Add a getContext and a getDomain function to the basic model
data point (localData element) so that AbstractField implementations
can use them thanks to their this.record element.
- Remove the autocontext binding for field RPCs (see FieldManagerMixin)
|
|
Use this.rpc instead of Model object, with web.ajax if necessary.
nb: EventDispatcherMixin include now the custom_events managment instead
of widget
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
|
|
When a message is not part of any channel, the message counter is
incremented while the message won't appear in any channel. This leads to
an inconsistency between the number of messages displayed in the status
bar and the actual messages in Discuss.
opw-706884
|
|
|
|
With how the chat manager was currently started, the "Odoo Session
Expired" could cause an arcane js error which would overshadow it.
This is caused by doing an RPC request too soon which invalidate the
session too soon which disable web client `show_application`.
With this commit, we have the error message "Odoo Session Expired"
instead of:
"Uncaught TypeError: Cannot read property '$el' of undefined"
closes #15313
opw-706346
|
|
84a650e33aadb29661121410813e3de37a5ad3e9
|
|
Group-based channels automatically add people belonging to user groups to the
channel. If a member leaves the channel he will be automatically added back
by the channel automatic subscription. This generates unnecessary changes and
messages in the channel.
We now prevent people from leaving group-based channels. All group members
have to be channel members. Unsubscribe buttons are therefore removed for
those channels.
|
|
In ff56304f58c a solution was tried to have message posted from
backend livechat linkified for visitor in frontend. This was
forward-ported when it should not have been and introduced issues
including:
- `href="{link}"` would become `href="<a href="{link}">{link}</a>"`
- if html entities such as the ones for U+00A0, and entities <, >,
', " or ` were next to the link, the entity would be linkified
too (up to the ;)
This happen because utils.linkify function is to be used with text
content and not html which was the case in this instance.
opw-693457
opw-702410
|
|
|
|
|
|
session.context no longer exists, it is session.user_context
Add the missing context in the message_fetch call. The dates in the chatter were
not formatted according the user locale.
|
|
The tacked messages in the chatter were parially translated.
e.g. "Lead created"
The call did not gave the user context and the subtype message was not
translated.
Closes #14589
|
|
|
|
(opw: 693457)
This fix is only intended for saas-12, do not forward port.
A better refactoring should be done on master to properly fix this issue
|
|
|
|
|
|
A traceback was generated when starring the '/help' bot.
opw-681626
|
|
|
|
|
|
|
|
|
|
Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.
opw-687781
|
|
There already is a redirect implementation in the chat_manager
which closely matches the on_redirect implementation in chatter.js,
however the former has the advantage of calling get_formview_id
to ensure that the view is correct.
This fixes a faulty behaviour when some models are referenced from
chatter message using data attribute data-oe-model and data-oe-id.
For example, linking invoices in the chatter would always open them
with the 'vendor invoice' view; from this revision on the correct
view will be used (assuming get_formview_id is implemented on the
model).
The default behaviour of the chat_manager when a user clicks on a
partner record is to open a channel if the partner has a user then
return a callback passed as a parameter (usually to open the channel
as a popup or in the discuss app). To keep the old behaviour
of the chatter followers list widget (i.e. open the partner form
when clicking on a follower), a small change has to be made on the
redirect implementation: when no callback is provided, do not create
the channel (instead a returning an empty callback).
|
|
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
|
|
|
|
|
|
|
|
When a user sends a link thanks to the livechat, the link is not
clickable is the recipient is on the frontend (e.g. visitor of the
website). On the other hand, a link sent from the frontend to the
backend works.
This is because the message is sent as "html" from the backend,
therefore no link conversion is done during the post-process of the
massege (method `message_post`).
Note that a link sent and received in the backend works because
additional formatting is done (convert emojis, add links...).
opw-686063
|
|
Before this commit, if a message thread was loaded 2 times, the first time
the date was well formatted, the second time that fail because momentjs cannot
parse the localized date from some locale.
Luckily, it was not bugged by default in english, because moment was able to
reparse a localized US date. But in some local as french, momentjs cannot parse
the localized date and return 'Invalid date'
Now, we move the code, to be processed only once by the chat manager, and not
in each process of the thread.
This commit closes issue #13258
Courtesy of @aab-odoo
|
|
|
|
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).
|
|
|
