The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: for 10.0 up to not including 11.0 which is fixed by #26911
opw-1877663
closes#26912
Before this revision,
Assigning a user for which its partner is inactive
was sending the assignation notification email to the `partner_id`
of the object.
e.g. Assigning a task to a user for which its partner is disabled
sent the assignation notification email to the customer of the task.
opw-787659
SAP sends out emails that only contain a PDF part, without a text or
html body, e.g.:
X-Mailer: SAP NetWeaver 751
Content-Type: application/pdf; name="Afleveringsbewijs.pdf"
Content-Transfer-Encoding: base64
Content-Description: Afleveringsbewijs
Before this patch, this single non-text part was parsed into the body of
the final message, as if it was a text part.
Making the check for the main part more restrictive solves the issue, as
there is no reason to assume that a non-multipart content is
necessarily of text/* type. This PR also includes a regression test.
Closes#21102
`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)
In 599bd509 for inline image in a mail the `Content-Id` of the
attachment was used as the file name to avoir an issue of several inline
images with the same name only displaying the first one.
This solved the issue but with it the file name when downloading the
image were lost as well as the extension which can be an issue.
This changeset refactor the code so the behavior stay the same but the
original file names are kept.
opw-725305
Fix some dead code. This is a fallback for linking mail attachment with
its data. The issue was not reported since a long time since this just
disable a fallback which in my tests was not used anyway.
opw-710502
A couple of places in the processing of bounces only
accepted a single matching partner. But there could
be multiple partners matching an email address, and
we should handle them all.
There might also be no matching `bounced_thread_id`
matched by the regex, so we should guard against a
bounced_thread_id == None.
This partially reverts commits 5d746d0ac6 and
73de86c768.
The tightening of access rights was too strong: regular users need to be able
to read models and fields (to create an email templace, for instance.)
[FIX] ir_values: in `get_actions`, exclude field `code`
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
Posting on a document not inheriting from mail_thread was impossible
due to several crashes or wrongly set variables. Some cleaning is planned
in those methods as there are a lot of unnecessary computation. This will
be done in another commit. Probably.
Before this commit, 'select all' into a list view, and use an action that assign
a user_id to all the records will send n² email, because the function send_mail
use active_domain instead of the current record.
Now, we keep mass_mail mode, but simulate the case where we have clicked on
each record one by one and not all the records matching the active_domain.
So we send only one email by record.
How to reproduce:
create a action server "record.write(dict(user_id=env.user_id))"
add this action in context menu
select all records in a list and apply the action server
When you write on user_id in a model, that will automatically send an email
to the new user_id assigned.
In case where it is write in batch, that can be considered as spam.
In some case, the user will be aware from another way that with this email.
When Odoo sends emails their Message-Ids are either generated by Odoo or
use the original Message-Id in the case of an incoming email going through
the mail gateway.
When the mailgateway handles replies to those emails it checks their
References or In-Reply-To in order to find matching Message-Ids and find
the reply's parent. Currently it is limited to Message-Ids matching the Odoo
pattern. However if an external email began a discussion thread, references
will not hold any odoo-like pattern.
Previously to commit 0028c42136 this was hidden due to a bug when
managing private messages. This code was also managing replies to external
emails due to a probably undesired side effect.
Correct way of checking if an incoming email is a reply to a thread is to
check that References or In-Reply-To Message-Ids match some stored Message-Ids
of mail.message. They don't have to match Odoo patterN
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
As this button leads to a void form view without context it is not
really usefull. As creating new records is achieved using aliases
there is no real need for a New Task/Issue/Note button.
mail/new controller is kept for compatibility but should be removed
before v11.
Old versions of Odoo did not correctly manage message_id of mail messages.
Thread formation was based on information present in References and/or in
In-Reply-To of replies to emails. Message-Ids could contain model and
res_id of a record. Thread formation was done using this information.
However commit 8253453d64 fixed that behavior
by correctly checking in existing mail_messages to find matching message-ids.
Message found was set as parent and thread formation was correctly done without
collision or possible issues with badly formatted Message-Ids.
A compatibility mode was introduced at the same time to handle previous versions
of Odoo. This commit removes this compatibility as it was done long enough
to ensure compatibility is not required anymore.
[TESTS] mail: tests updated, compat mode should raise in all cases now
Move code related to redirection in its own class method. This way all
controllers perform their own actions and checks before calling the
redirection itself. Moreover it is necessary for some controllers to be
able to call the redirection independently outside of the mail/view
controller scope.
This commit also fixes some links generated for mail notification email
buttons. Assign and (un)follow buttons now effectively use the link helper
when generating the associated URL instead of manually crafting it.
Custom routes for notification buttons used in HR and CRM are added.
Indeed in order to be able to fine-tune the behavior called by those
buttons, using dedicated controllers is simpler than trying to use
a generic one. As there are few custom buttons in notification emails
using dedicated controllers does not lead to a code overhead.
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
Christophe Simonis