fails due to ir.config_parameter permission
At rev. 80017b04c2
ir.config_parameter model has been restricted to employees
Getting parameter from this model should therefore
be done as SUPERUSER_ID where the uid could
be a user which is not an employee.
Closes#5280
Acting as a mailing-list-like distribution system, the system used
to set the enveloper sender (aka bounce address) to the From header
of the message, effectively pretending to be the original sender.
In some cases the domain of the From header explicitly forbids
sending emails from external systems (e.g. with a hardfail SPF
record), so this could cause the email to be rejected by some
spam filters, depending on their policies.
The system will now use a local bounce address in the form:
mail-catchall-alias@mail-catchall-domain
or, if no catchall is configured:
postmaster-odoo@mail-catchall-domain
(as soon there is a mail.catchall.domain configured)
It will only fallback to using the From header when no
catchall domain is configured.
Fixes issue #3347.
Closes#3393.
Rev f2cf6ced1 modified RFC2822 parsing in order to better support
unicode characters inside the Name part of an address header.
However the patch broke handling of multiple addresses (comma
separated) - silently discarding all recipients except the
first one, as soon as any non-ASCII character was present.
This patch restores the functionality while preserving the
fix from f2cf6ced1, and simplifies the code using email.utils
utility functions.
Fixes (again) lp:1272610, OPW 607683
When sending an email, both formats 'Name <email>' or '"Name" <email>' can be used for fields 'From', 'To' and others. If the name contains unicode characters, a regex only matching '"Name" <email>' was used to encode the name with RFC2047. That meant that the name was not encoded and eventually dropped, using only the email part.
Instead of using a limited regex, use the parseaddr method from email library.
Fixes lp:1272610, opw 607683
Many mail clients will replace the name in the To:
header with Me if the To: email matches the email
of the user. These users will see To: Me instead of
"Followers of ..." and usually believe this was a
private email from the sender to them.
But when replying they would reply to the whole list.
Fix this by explicitly forcing the To: to be the
mailing list address.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
The previous fix in revision 5072 only allowed user names
that contained the exact same emails, but users will do
the wildest things like having `someone@domain.com` as
name but setting their email to `someone@domain2.com`.
This was blocked by our sanity check looking for a single
email in the From header. As this check is only done
in order to provide a better error message, it should
not impact valid cases.
Modifying the check to pass when at least one email
was found should be enough to catch most invalid cases,
without requiring a more advanced analysis of the
header value (the RFCs allows very strange things!)
bzr revid: odo@openerp.com-20130918143807-wqqpqomyu1ppa2ih
When a user has their email as name, the system will
construct the From header as "email<email>".
We previously forbade this, because the naive
check only counts the number of emails in
the From header.
We might need to drop that assert or implement
something better in the future.
bzr revid: odo@openerp.com-20130910143809-wu32dkz20es579nv
When --test-enable is used, it is expected that test output is visible,
thus using log-level INFO is natural.
On the down side you lose the nice blue hint that tests did actually
run when --log-level test was given.
bzr revid: vmt@openerp.com-20130326155844-83e2tcqokvblr0ln
The default Python encoding for mail header parameters
is RFC2231, which produces headers of the form:
Content-Disposition: attachment; filename*="utf-8abcd%C3%A9.pdf"
This works fine for e.g. Thunderbird but on GMail
such headers appear as `noname`.
We are therefore falling back to RFC2047 encoding
which will instead give something like:
Content-Disposition: attachment; filename="=?utf-8?b?UmVxdWVzdCf?="
bzr revid: odo@openerp.com-20120316130803-zo4fwuk7h6bq6k54