The dataset of an x2m could be set as changed on a focus event, but if
the form is currently not in editing, it could stay blocked in this
state.
This commit add a check so blur and focus on x2m are better coupled.
opw-665401
A partner can be associated to multiple users.
The condition checking the partner
user has enough karma should therefore
handle it. The previous condition expected
a singleton (only one user for the partner).
With the condition before this revision,
a partner with multiple users could
simply not post new questions on the forum.
opw-667894
The default behavior of session.rpc is to block the ui if it is not
completed in some short delay. This is not really good for various
types of rpcs. The discuss application is actually doing quite a lot
under the hood, and blocking the ui for some of those use cases does not
make sense (exemple: marking a channel as seen)
When creating a XLS file with more than 256 columns, the library used
(xlwt) fail since it is targetted to support MS Excel 97 up to
Excel 2003.
But Odoo doesn't has no check and in this given instance (an error
happening in a controller generating a binary filte) the real error
message is lost.
This commit check if the to-be exported data has more than 256 columns,
and if this is the case display an error message without even trying
the export.
closes#10630
opw-660474
This commit does not actually fix qweb2.js, but it works around a
phantomjs bug. The problem with phantomjs is that in some situations,
the xmlhttprequests are dropped with a status 0. It is most likely
related to the issue:
https://github.com/ariya/phantomjs/issues/11195
In our testing framework, it seems to appear when requests sent before
the 'load' event of phantomjs are received after, and also when those
requests are listened with the onreadystatechange handler.
The bug does not appear if we use addEventListener with the 'load' event (at
least, not for a few builds)
This commit does not worsen qweb, and it is also a small improvement in
style (in my opinion).
When categories on the point of sale take too much height, the product
and overflown categories are not visible.
In those instance Odoo wizards would usually:
- use an option to have small categories without pictures,
- have a category "all" with all the product,
- do a custom change to reduce the size of categories or add a scrollbar
This commit add the last customization in stable.
If the category block is bigger than 60% of the page height, the
categories are cropped and a scrollbar is added.
closes#10588
opw-660383
This could allow a malicious flow that made the quotation available
via the website_quote module; allowing you to sign and confirm the
order without actually paying it.
When performing a stock valuation at date,
the stock valuation total wasn't equal
to the sum of each line of the report.
This is because the domain forcing the
date wasn't passed to the `search` call
when no group by was applied.
Indeed, when calling
`read_group` with a group by, the lines in the results
contains the domain used for each line, but when
there is no group by applied, this is not the case, the domain
is not included in the line dict returned by `read_group`.
In such a case, therefore, we must use the domain that was passed to
the `read_group` call.
opw-667761
The definition of "total" as a global variable is done too soon in the
JS. Depending on the order in which the JS modules are loaded, it is
very unlikely that the translations are already loaded at that moment.
opw-666577
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.
Nicolas Lempereur