When a replying to an email, the matching alias should first verify access
via the parent record if exists (i.e. check on the project instead of
on the issue itself).
Some one2many fields are called with a many2many widget to unlink
records instead of delete them. But this behavior was modified with the
new views and the records were deleted anyway.
In this commit, we restore the previous behavior, and create a FORGET
command in basic model
to do that. Note that the widget='many2many' is a hack, and a better way
to accomplish this is to use a new custom option. But this would be a
fix for master (PR #18413)
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
In the chat, there is an indication of when a message was sent, This indication gets updated as time passes. When the last one in the conversation is updated to an indication that takes more space (e.g. from 'now' to 'a minute ago'), the text below is pushed lower (as expected) but the chatter does not scroll down. As a result, we do not see new messages, unless manually scrolling down.
(PR #17469)
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
-added tour for invoicing
-allow to set easily the number of the first invoice/bill/refund of a journal, from the invoice screen
-small usability fixes and refactoring
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>
When a chatter is created, appended, and destroyed before being ready,
bad things could happen. This is because the code in start/other
deferred was executed regardless if the widget was still alive. And,
some mechanisms, such as _getBus, depends on the event system. If the
widget is destroyed, it will be remove from the component tree and such
functions will then return undefined.
To protect agains those issues, we simply make sure that the deferred
are only resolved when the widget is still alive.
This widget hasn't been rewritten with the new views.
The purpose of this widget is to open a popup for each invalid partners
(without email) in a many2many to fill the email. If the email is not set, the
partner will not appear in the tags and its id will not be sent (which should
not be the role of a widget but that's the way it is).
Replace `model.search([('id', 'in', ids)])` by `model.browse(ids)`, which is
safe because `ids` come from reading a many2one field. The performance impact
is negligible.
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
Mail now can handles a generic access_token in /mail/view route. Mail does
not do anything with it. Addons can override the controller and add their
specific management of this token according to some specific business
logic.
Sale order emails now contains the access token to grant access from the
notification email url without logging in. Sale portal now allow customers
to log in using an access token without having to use Online Quote. If
the user doesn't have an account yet and signup is allowed (B2C) an extra
parameter is added to the url to link the correct partner to the user upon
signup. If the user already has an account an extra parameter is added to
auto-fill the user's login if he wants to login from that session.
Account is also updated to prepare accepting access tokens. However the
complete implementation of accounting customer portal will be done in
another task coming soon.
Xavier Morel