When using a template adding the signature, do not re-add it when posting
the message on a document. For example the Sale Order - Send by Email
templates generated two signature in the email.
This issue has been introduced when migrating mail to the new API.
When the delimiter '@' is used in the composer, a regular expression is
built in order to suggest followers. However, if this regular expression
is incorrect, it causes a crash since RegExp will throw a syntax error.
Since a new regular expression is built for each new character the user
types, this situation can occur very easily. For example, typing '@('
will cause a crash.
This fix replaces characters which may easily lead to a syntax error by
a space.
When no update has been done on website, we don't have this default-lang
data/attribute. So we use an hack to find the default lang which one is
the shortest because no lang is present in the url.
Most occurences of the fullscreen feature have
been removed in the below revision:
eebdbb677fdee1163c16ec2bb967f37e1e4b69e
Only the field has been left.
This isn't allowed to go fullscreen
without a direct user click
by most browsers, for security
purposes.
opw-658838
message_get_email_values is declared as receiving cr, uid, id. However this method
is an override of a multi method. A decorator has been added to tell that id is
actually a list of ids and avoid list encapsulation issues with the result. This
way the method parameters are not changed.
[CLEAN] mail: removed some unused imports, by the way
This computed field allows to know whether the current user is a channel
member or not. This is necessary to fix the join / leave action button
on channels. It was still based on the followers and has not been updated
with the new v9 model of channel members.
Now that channels can follow documents, restricted aliases are a bit too
restricted. We consider that followers-based aliases accept emails from
the direct followers (message_partner_ids) or member of non public
channels (message_channel_ids, filetered public field). This way we avoid
having public channels added by mistake, leading to information leak.
Not being able to add / remove members of a channel through its form view is
quite limitating.
Also added the followers widget in the channel form view in technical mode.
Indeed it is sometimes necessary to be able to check a channel followers.
When making several expenses for the same analytic account,
it can be possible that these expenses have the same product but different
price unit(e.g.:this is the case for plane ticket with a vairiable price
according to the time). Then the function "_get_sale_order_line" must check
for all the existing confirmed SO lines if there is one which matches with
the analytic account, the product and the price before creating a new SO line.
opw:658383
In a multi-currency environment, the difference amount computed will be
affected by the exchange rate change. In other words, if the exchange
rate changes between the invoice date and the payment date, this
difference will be reflected in the difference amount. For example:
- Company currency is USD, invoice currency is EUR
- At invoice date, 1 USD = 1 EUR
- At payment date, 1 USD = 0.9 EUR
- An invoice of 1000 EUR is created
- A payment of 1000 EUR is done
Without this fix, a payment difference of -100 EUR is shown. The reason
is that at invoice date, we expect a payment corresponding to 1000 USD,
which is equal to 900 EUR at payment date.
This fix doesn't do any currency conversion if the payment currency is
the same than the invoice currency, to prevent any exchange rate
difference shown. Indeed, if an invoice is 1000 EUR, a user expects that
a payment of 1000 EUR will not show any payment difference.
Note that this doesn't fix the payment difference amount when an invoice
in a given currency is paid in another currency.
opw-658177
On a payment form, the company currency is obtained from the journal.
This means that as long as no journal has been selected, no company
currency is defined and the payment difference is wrongly calculated.
This fix uses as company currency the currency of the user's company if
no journal is chosen, which should be a safe choice and lead to a
correct calculation of the payment difference.
opw-658177
Add 'base' as a requirement to be sur that dom is ready
before to bind the popover on the cart.
Without it, the popver is just never displayed.
Bug introduced during ref 71732dc.
The read_more button displayed in long messages is an <a> inside a <span>, both
having classname oe_mail_expand, and an handler in bound on that classname
since rev. 169f819a. This handler was executed twice when clicking on that
button, toggling twice the message's bodies long and short, thus doing nothing.
When a user records an activity or a timesheet entry on an analytic
account not linked to a SO, the employee's cost is not taken into
account. This is due to the fact that the search of the timesheet cost
is only performed if there is a SO line.
This fix uncouples the SO line search with the timesheet cost search,
since there is no reason to link them.
opw-657899
Project users should have acces to the Search menu in project. Indeed it
contains the tasks and issues menu entries, allowing to directly jump
to a custom list of task / issues.
Since a2b94b0b6d, we already push the cost
of deliveries on the DO (it may be a grid or a carrier).
So we simply harmonize the behavior: when a DO is transferred,
_add_delivery_cost_to_so() is always called (it will check whether the
delivery costs are to be added to the SO or not)
bus.poll() should be a private function, as it initializes a new longpolling.
Only bus.start_polling() should be called as it prevents running multiple
polls concurrently.
On the website, bus.poll() was called each time the user clicked on the
livechat button, blocking the whole UI if the user clicked 6 times in a row on
that button, as only 6 RPCs can be done concurrently.
A consequence of this fix is that the poll isn't restarted if the user opens
a new livechat session just after closing one, so the messages sent through
that session are delayed (~50 seconds). To circumvent this situation, we simply
don't restore the livechat button after closing a livechat session (the button
re-appears anyway at the next click, or after a refresh).
Long messages are not displayed entirely, but a 'read more' button is displayed
and allows to show the whole message. This button is an <a> inside a <span>,
both having classname 'oe_mail_expand'. Also note that messages are html, not
plain text.
Sometimes, the long message is truncated at some point that the 'read more' is
inserted inside an <a>, which is not html valid (nested links). In this case,
the browser automatically moves the inner <a> out of the outer one.
Unfortunately, when that happens, clicking on 'read more' redirects to the app
switcher because of missing prevent_default(), as the event handler was bound
on the <span> clicked, not the inner <a>.
This rev. simply binds the handler on 'oe_mail_expand', not specifically on
its <span>.
Before this rev., only the root user was allowed to do so, because some
operations were performed on the channel just after the user had been
unsubscribed (to trigger the unsubscribe notification on the bus, and to post
the 'left channel' message).
When several channels followed the same document, and a message was sent in
this document, the unread counter of each channel was incremented by the number
of following channels (because as many notifications were sent on the bus, and
for each notification, we incremented the unread_counter of the channels in
which the corresponding message is posted).
This rev. makes sure to only increment the unread counter once, if the message
is not yet in the JS cache, i.e. if this is the first notification we receive
for this message.
- don't display subject for messages coming from chatter
- better tooltip on the leave channel button in client action sidebar
- don't squash nearby messages in chatter
- reduce margin of date separator in chat windows
When the kanban view is grouped, it did not correctly set the ids of the
dataset. Consequently, the user could find himself in some weird
situation, such as having X issues visible in a kanban view (typically
grouped with a custom filter), then clicking on it, and arriving in a
form view with Y issues, and X != Y.
Thibault Delavallée