Create an activity in a chatter, mark it as done, click inside the
textarea, the popover is automatically closed.
The `click` trigger both opens and closes the popover on click.
opw-2028399
closesodoo/odoo#34982
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Create an invoice for a customer, send him an email from the chatter, in
the mail template set a specific "Reply to" and send the email. The
"Reply-To" template mail header is ignore and the one generated by
`mail_thread._notify_get_reply_to` is used.
See also 1c57d5e and 7b0806b
opw-2041640
closesodoo/odoo#35127
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Since Chrome 74 or 75, tabs in Discuss suddenly disappeared.
Normally, these buttons are displayed at the bottom of the screen
when you open the Discuss app.
So we had to review this part and it seems more logical to override
the "height: 100%" property with "min-height: 0".
By doing this, the flex box element can grow from this size.
We also set flex-shrink to 1 to reduce the content with a scroll-bar
to let enough space to the other static elements (flex 0 0 auto).
Note that these rules are only applied on mobile.
opw-2030433
closesodoo/odoo#34947
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
When an email is sent and is related to a record, there is a header with a
button link to access the record.
Before this commit, that button href was always linking to the base_url URL.
That was an issue on multi-website, since we need to use the website url and
not the base_url if the record is related to a website.
That's the case for a SO eg, after checkout you receive a confirmation email.
In a multi-website environment, we need to access the record website.
To do so, a previous imp/fix was done with c1be1993f9.
But this occurence still needed to be replaced.
Fixes#34309closesodoo/odoo#34397
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Add record to the email values to allow the use of more complex
email layout as : "mail.mail_notification_paynow"
opw-2025099
closesodoo/odoo#34375
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.
This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.
Task-ID 2026101
closesodoo/odoo#34291
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Changing the 'public' attribute of a mailing list to "Public" (e.g. to publish
it on /groups page), was triggering the _onchange_public which changed the
visibility of the mail.alias to public.
This was incorrect as a channel may be public but it does not means everybody
should be able to post in it. It is still possible to restrict the access to
specific members only (and it is probably a good reason to avoid spam).
The intention of 66bd7707f5 was to protect the private channels
by default but had the opposite effect if the visibility was changed.
Changed the onchange evaluation to only restrict the access when unpublishing
a channel but do not force it at public.
Context: unpublishing and republishing a mailing list had the effect to change
the alias privacy to 'everyone' and we received spam
closesodoo/odoo#34105
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Create an invoice, validate it, print the invoice from the print menu,
as of the paperclip value in the chatter, an attachment has been added.
But if you click on the paperclip, there are no attachments. You need to
reload the page in order to access the attachments.
The problem is the internal flag indicating that all attachments are
fetched is wrong. This fix resets the flag when the paper clip value
changes.
opw-2008344
closesodoo/odoo#34171
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, it was not possible to have the field message_attachment_count
explicitly defined in the form view. It crashed inelegantly if it were the case
After this commit, it is possible to have that field in the form view
OPW 1998503
closesodoo/odoo#34143
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.
The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.
opw-2006647
closesodoo/odoo#34076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When sending a message (e.g. in a CRM lead or SO),
a failure_type and failure_reason are displayed, even when the message
is successfully sent.
This is because these fields are not updated when the email_status
is changed to "sent". We reset these fields to '' when the message is sent.
OPW-2003290
closesodoo/odoo#34082
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33943
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
The stable behaviour of the mail composer is the following:
- if a template adds new attachments, the composer only has this list
- if a template doesn't add attachments, the list is unchanged
- if no template is set, the list is cleared up
In the case of templates, we also check that both static and dynamic attachments
are added to the list.
We clean up after c6d718f211 and subsequently 516f22c398 which failed to take
into account the fact that the attachement list could be a blend of commands
and ids.
Transforming that is taken care of by _convert_to_write, which semantics was
changed by c6d718f211.
To keep the second behaviour, we thus need to add a (5,) command.
opw 2003197
closesodoo/odoo#33706
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The stable behaviour of the mail composer is the following:
- if a template adds new attachments, the composer only has this list
- if a template doesn't add attachments, the list is unchanged
- if no template is set, the list is cleared up
In the case of templates, we also check that both static and dynamic attachments
are added to the list.
We clean up after c6d718f211 and subsequently 516f22c398 which failed to take
into account the fact that the attachement list could be a blend of commands
and ids.
Transforming that is taken care of by _convert_to_write, which semantics was
changed by c6d718f211.
To keep the second behaviour, we thus need to add a (5,) command.
opw 2003197
closesodoo/odoo#33707
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fine-tuning of 516f22c398.
This commit missed attachments that are linked to a mail.template,
which should be added to every mail sent using the template.
To make sure that we both fix the duplicates and the generation issue,
we add a test.
opw 2000515
opw 1998782
closesodoo/odoo#33528
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Open a mail.compose.message wizard.
Select a template that generates an attachment.
Reselect it. A second attachment has been generated.
Can be repeated ad infinitum.
At template onchange, the template is rendered to overwrite the composers values
This includes the attachments.
Let L1 be the list of attachments generated by the template.
When _convert_to_write(values) is called with {'attachment_ids': L1},
it gets self.attachments_ids = L2, and generates a [(6, 0, L1 + L2)] command.
As a result attachments are only added,
the previous ones need to be removed manually.
Since c6d718f, the semantics of _convert_to_write changed.
Before, it always returned an empty list for new records (without an id).
In other words, wa always had L2 == [].
As a result we need to adapt the wizard to keep its old behaviour.
To solve it we bypass the _convert_to_write for 'attachment_ids' and directly
generate the 6 command with the list of ids L1 generated by the template.
We only do this for templates that add attachments to keep the templates
composable (a template only overwrites the values it defines).
Unfortunately, we don't have any way to know which attachments have been added
manually, so we can't preserve these (which was the old behaviour anyway).
opw 1997430
opw 1987169
opw 1998115
opw 1998782
closesodoo/odoo#33387
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When multiple emails (`mail.mail`) are linked
to the same message (`mail.message`),
all the message notifications were being marked as sent
as soon as one of the mail was sent, and not all of them.
This is indeed possible to have multiple emails linked to a single
message, for instance when there are employees and customers in
the followers of a thread, and some must therefore have
the buttons meant for the employees ("Assign me") and some not.
In other words, it was possible notifications were marked
as sent while their associated email was not sent yet.
This revision also comes as an addition to
5d6656d739
as it was possible to receive a bounce coming from
the previous mail sent which wrote on the same notifications `email_status`
than the current message being sent before we could acquire the lock on
them (see commit message of the above mentioned revision),
as it was writing the `email_status` on more notifications that it
should have, including notifications of the previous email.
e.g
- Mail 1
- Message 1
- Recipient A, B, C
- Mail 2
- Message 1
- Recipient D, E
Let's say recipient A bounces
If the email notifying the bounce arrives during the processing of the "Mail 1",
it will be blocked until we release the lock on the `mail.notification` `email_status`
we acquire thanks to having written `exception` on `email_status` before sending the email.
But, as soon as it is unblocked (after the `cr.commit()`),
it will immediately re-attempt the delivery of the bounce email,
therefore writting "bounced" in `email_status` of recipient A,
while the transaction of the second email already began.
When the second email sending will try to write the `email_status`
of recipient A as well
(as it used to write the `email_status` on all the message notifications,
not just the one related to the current email),
it raised a concurrent update.
Therefore:
1. Interrupting the loop, as psycopg2 exceptions are raised and not passed,
2. Replay the sending of the second email a second time.
opw-1984293
closesodoo/odoo#33431
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
If the smtp session was dead, it would lead the whole mail batch to fail.
opw 1949270
closesodoo/odoo#32424
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
closesodoo/odoo#33350
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fine-tuning of 463601a384.
It does not make sense to be able to write on mail.activity.type
using the related fields defined on mail.activity.
But this field is not a related one, and it is necessary to be writable to make
the 'recommended next activity' feature work at all.
opw 1974236
closesodoo/odoo#33325
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Julien Castiaux