This allows linking databases to contracts in the central
contract registry, and automatically updating local databases,
simplifying the registration procedure for users.
Closes#10323
- prevent concurrent opening of the chat window
- take into account the placeholder value of the livechat session record
- don't send welcome message if empty
Problem is that when someone is mentionned in a channel he doesn't belong to
(public, private or DM whatever), the message only appears in its Inbox and
he can't know where it comes from nor reply. This is thus very confusing.
With this rev., in Discuss, one can only mention members of the channels.
In the chatter, anyone can be mentionned like before, as when the message
arrives in the Inbox, there is a link to the associated document.
When using multi tabs or browsers, the 'New messages' separator in threads was
sometimes wrongly displayed (displayed over messages already seen in another
tab or browser).
Problem was that since rev. 617968c61, we consider sent messages as read client
side. This has been done to avoid to indicate that a channel has unread
messages e.g. when this channel is a follower of a chatter in which we wrote
a message.
This change has as consequence that we don't perform the 'channel_seen' RPC for
messages sent. At each refresh, the server sends information about pinned
channels, especially the unread counter, which was thus sometimes incorrect.
This rev. simply doesn't take messages we wrote into account when computing
the message_unread_counter field.
Also correctly display the 'New messages' separator in threads, by automatically
skipping messages we wrote (i.e. it is now displayed above the first message m
with m.id > last_message_seen_id and such that we aren't the author of m).
- limit partner search to 10 in new message's chat window to prevent overflow
- prevent negative needaction counters (may occur in multi-tab, with
needactions received during an inactivity period)
- remove <pre> tag when computing messages' preview for the messaging dropdown
as they break the layout and add 'overflow: hidden' on o_mail_channel_preview
just in case
- rename 'New message' button in Inbox into 'Send mail' as it was confusing,
and adapt .pot file accordingly
- focus on composer when opening a chat window
- break lines in threads to avoid horizontal scrollbar (credit goes to qsm)
- correctly apply rules on <p> in threads
opw-667235
The amount was 3,8560.96 because the Benelux pricelist was
applied by default, due to a regression introduced by
698c0c557d
while it should have been the public pricelist loaded
by default.
Both the benelux and the public pricelists were available,
but it should be the public pricelist chosen by default,
as it's the default website pricelist.
See bf78ad7bf7 for more
explanations.
If a user signs in, and as a previous unfinished
order, it loads it only if the pricelist set on this
sale order is amongs the available pricelists.
Otherwise, he could benefit of prices that
are no longer available.
If a user signed in, the pricelist must be,
in this very specific order:
- the pricelist of its saved cart
except if the cart is no longer valid
(pricelist no longer available or
order no longer draft),
- or, the user specific pricelist,
in other words, the pricelist set by an employee
for this specific customer, if any,
- or, the public user pricelist, if it is available
in the user geolocalization
- or, the first pricelist available
In addition, if the user firstly browses the shop
without being signed in, and then signs it, the pricelist
loaded after the sign in must be the user specific pricelist,
if any, and not the default website pricelist (the public
user pricelist or the first pricelist available)
opw-666620
This revision reverts e5b9f02f7a
The argument `website_pl` must always be the default website
pricelist (the public user pricelist), as stated in this
method documentation:
```
:param int website_pl: The default pricelist used on this website
```
So the difference between the public user pricelist
and a specific user pricelist can be made.
A special pricelist set for a specific customer must
always be amongs the available pricelists.
opw-666620
In a survey question of type `matrix`,
nothing prevents to remove a row from the matrix,
even if there are already answers for this line.
If the case happens, the row is deleted, but
not the answers. The answers are therefore orphan.
The answers should probably be deleted when the
row is removed from the survey, but this is a risky
change, and, even, users might want to keep track
of the answers given even if the line doesn't exist
anymore in the survey.
Therefore, we just handle the case when displaying
the survey results,
we ignore matrix answers for which the row no longer
exists.
opw-666393
During the construction a xml/html_translate content, in case of a wrongly
translated part (e.g. not correctly escaped char or bad xml tag), escape the
translation.
The verification is done during the rendering on the view which is not the most
optimal solution but has the advantage of working on system with some broken
translations and does not requires to reload the translations.
In master version, the verification could be done when loading the .po files.
Suggested alternative descriptions spill out of the boxes if the
description is too long.
PS: same fix as in saas-6 with f7110b46be.
This fix doesn't have to be forwrad ported.
opw:667343
The write-off currency should be the currency of the first
account.move.line, since it is what is assumed in the interface.
Moreover, the sign of amount_currency should match the constrain
_check_currency_amount.
opw-667137
The Purchase module provides a functionality to add pre-filled invoice
lines to an invoice. The issue is that extensions of the accounting
modules might add fields on an invoice line, and one would like to see
these fields populated as well.
This is the case for account_asset, which adds an asset_category_id on
an invoice line. However, the Purchase module is not aware of the fields
added by account_asset, and therefore it cannot populate them.
This fix adds a method, _auto_fill_extra, which is intended to manage
these extra fields.
opw-667162
When writing several times on the same record in the same transaction,
the orm raise a Missing error because the rowcount only gives one
difference.
opw:666470
Nicolas Martinelli