violated in _search, do it in SQL to speedup the query. Indeed doing it via search and
browsing the results to validate the various rules is quite costly.
when the email is not a notification, or not an email usign the automatic
threading. This means that when doing mass mailing with a fixed reply_to
there won't be any link to access the original document, which is what
we want. Otherwise when mailing partners, they have a link to access
their own partner profile, which does not make sense.
The forward port of the fix 3609ba10f2 will be done separately, as the mrp scheduler has been completely refactored from saas-5.
Conflicts:
addons/l10n_be_coda/wizard/account_coda_import.py
addons/point_of_sale/static/src/xml/pos.xml
addons/procurement/schedulers.py
This avoids storing useless "{}" values
in the database when there are no headers,
and avoids having to update all existing
entries when this column is added.
Just requires simple tests before evaluating
the headers contents.
- [FIX] bounce regex: too many emails were considered as bounce and therefore
not displayed in the chatter and lost for the communication history. The regex
was not correctly looking for the bounce alias in the email_to.
- [FIX] invite email: replying to the invitation email (invitation as new
follower) now replies to the user sending the invitation.
- [FIX] mass_mailing: added a column to store the id of the original email
in addition to the many2one column. The many2one is set to null when deleting
the original email. As the information is necessary, it is saved on another
field. The many2one is necessary for indexes purpose as the inverse of
a one2many.
This can give a performance boost on large databases
and should not be a concern in terms of access control
as the inheritance already grants access to the parent
records.
management to access documents in notification emails, as well as for the
'view quotation' link in portal_sale module.
models: added a get_access_action method: basically, returns the action to
access a document. It uses the get_formview_action by default (form view
of the document). However for some documents we want to directly go to the
website, leading to an act_url action for some documents. This method allows
this behavior.
portal_sale: get_signup_url now uses the mail.action_mail_redirect method
instead of directly redirecting towards a portal menu. This allows to fall
back on a standard behavior.
portal_sale: get_formview_action updated, to match actions tailored for
portal users.
website_quote: get_access_action of sale order updated. If the sale order
has a template defined, the returned action is an act_url (website view
of the quotation), not the form action anymore.
mail: fixed signature + company signature in notification emails. Even without
user signature, the company signature + access link should be correct.
portal: signup url in notification emali was not using the mail redirection
as action. It is now the case.
When creating a new message, we need to reset the default_type key to avoid context propagation (e.g. invoice menu).
However we used to compare the key in context (char) with the list of selections (tuple) so it was never matching and always reset.
When a record is created, if it inherits from mail.thread, a message 'OBJECT created' is posted. 'created' is translated but the name of the model wasn't.
This fix uses the name of the linked ir.model which is already a translatable field.
lp:1262000, opw 611043
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Loading the menus is the most expensive
operation for an average page load, and
the result does not change often.
The menu filtering already uses a separate
cache based on groups, but the rest of the
loading includes reading actions and
translating menu names, which is also
expensive.
Added a cache keyed on user + user
lang, plus relevant cache invalidation
when any of the following are touched:
access rights, user data including
groups and language, menus or mail.group
subscriptions.
The menu filtering cache is still
useful in parallel has it is invalidated
under different conditions.
User.has_group() is cheap but still
called very often, so it is an easy
win as well, and also frequently
used when rendering page templates.
Replacing the browse+search speeds up
the filtering 50x, which is significant
for a method that may be called on most
page loads as soon as the user is
logged in.