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.
In saas-6, the pivot and the graph view have been
split in two separated type of views.
Otherwise said, there is no longer any graph view
with as type "pivot".
opw-658725
When changing the account_id of an invoice line, all the tax line,
created from this invoice line and with a tax which has no
"account_collected_id" set, must be set with the same account_id.
Inspired from the function "compute" in model "account.invoice.tax"
closed#9727
opw:657499
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
Backport of de3b64018a
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
close#9925
In saas-6 the editor assets were always included, in 9.0 only for
designer but if website_forum is installed it should also be included.
fixes#9402closes#9852
note: should not be forward ported after saas-8
The decimal precision displayed for the quantities
should be the same in the point of sale interface
and in the back-end.
Besides, the decimal precision of the pos order lines
quantity should be the same than the decimal
precision of the sale order lines quantity.
opw-657591
This commit fixes two bugs on followers:
- when landing on a form view, the followers' dropdown is now correctly filled
- when editing the subtypes of a follower while not being ourself a follower,
the subtypes are now correctly displayed in the modal.
Full composer messages were not loaded in the chatter when sent. We
lost that functionality sometimes in the previous months. This commit
makes it work properly again.
Some refactoring were required, we needed a way to load messages with a
given res_id and model.
message_ids contains the ids of all the messages. However, a maximum of
100 messages are fetched when a page is open, and therefore some
messages might not be found in the JS cache. This leads to
message.is_needaction throwing an exception.
This fix returns True if the message is not found. It means that the
message will be set as 'read' even if it is not displayed.
opw-657896