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>
When checking the rights when creating a new activity, c38a0d6768
made the choice to bypass the check if the multi-company case.
However the "multi-company case" was determined by checking that
len(target_user.company_ids) > 1; however if target_user.company_ids contains
companies to which the current user doesn't have access, then this is wrong.
Let the active user be Ua in companies C1, C2, currently in C1,
and the target user be Ut in C2, C3, currently in C3.
Then target_user.company_ids == [C2] for Ua, so the check would be False.
This shows that we need len(target_user.sudo().company_ids) > 1.
opw 1998709
closesodoo/odoo#33681
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#33653
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When receiving an email, an attachment is created for every base64
embedded image. We got an invalid image which caused the attachment
generation to fail with a traceback due to a base64 decode error.
The attachment creation has been wrapped into a try/catch in order to
remove problematic images.
opw-1987224
closesodoo/odoo#33620
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This commit fixes a js crash that occured when the user was trying to
edit a new record while the chatter was not completely loaded
(this.field.thread.$el was not in the dom yet)
Behavior before this fix:
Traceback js & impossible to edit the form afterward.
Behavior after this fix:
no traceback, still possible to edit the form normally.
The thread will display on next chatter re-render. Could be forced by
triggering an onchange.
opw-1986061
closesodoo/odoo#33381
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Jorge Pinna Puissant