Frequents calls to list.remove() were being a bottleneck for large
document lists (100k+). Using a set make remove() calls much faster.
This commit has a corresponding server patch in the core ir.attachment
search method.
bzr revid: odo@openerp.com-20120821131920-j653hvmff78fxxtr
* edi: improve generation/usage of edi_web_url_view for template rendering
- wrap edi_web_url_view generation to _edi_get_object_web_url_view() method.
- automatically add 'edi_web_url_view' to all email.template rendering context
- introduce LazyEdiWebUrlViewGetter class, to allow resolving record wihtin
template rendering context - only when necessary. This to prevent generating
unrequested edi_web_url_view links
* mail & email_template: allow to modify render_template context
- add _prepare_render_template_context() method to allow modifying context
before rendering template.
bzr revid: xal@openerp.com-20120820155601-appnnpp4p3a803nz
- wrap edi_web_url_view generation to _edi_get_object_web_url_view() method.
- automatically add 'edi_web_url_view' to all email.template rendering context
- introduce LazyEdiWebUrlViewGetter class, to allow resolving record wihtin
template rendering context - only when necessary. This to prevent generating
unrequested edi_web_url_view links
bzr revid: xal@openerp.com-20120820083456-teqk4kdqe8mv59p8
- add _prepare_render_template_context() method to email.template to allow
modifying context used for rendering template.
- override mail.compose.message wizard to use email.template's
_prepare_render_template_context instead of mail's one.
bzr revid: xal@openerp.com-20120820083047-a52nj5e113c0lniz
- rename '_pre_render_template' to '_prepare_render_template_context'
- _preare_render_template_context return a new context, which is distinct
from original method context - as we want to control more precisely what
context will be available to render_template().
bzr revid: xal@openerp.com-20120820081911-34h2zlzcrspfpyz6
Avoid locking the full users table unless there is
really at least one user record to crypt.
Avoid using a separate cursor that could create a deadlock
or TransactionRollbackError in the main init() transaction.
bzr revid: odo@openerp.com-20120813145200-cc0gfzz04aundxhw
Performing a full table lock is potentially very slow
due to the number of tables holding foreign keys towards
res_users, so we should avoid doing that for simple
auth check() calls. The point was only to avoid failing
the update of the last login timestamp, which we don't
actually care much about. So we can replace that with a
simple SELECT FOR UPDATE NOWAIT on that specific user
row and and skip the update in case the LOCK was
not granted
bzr revid: odo@openerp.com-20120813143552-3g3z0q9n1iox8a0b
Due to a programming error in the code, any message that had
several values in the References header create as many
duplicate copies of the message as they were previous
messages in the discussion.
Also cleaned up and simplified the code.
bzr revid: odo@openerp.com-20120810123753-c00y4l1276b8guqb
Due to a programming error in the code, any message that had
several values in the References header create as many
duplicate copies of the message as they were previous
messages in the discussion.
Also cleaned up and simplified the code.
bzr revid: odo@openerp.com-20120810114838-k273zok10911l6ij
The menus were properly restricted but the portal users
created through the portal wizard on Partners were
erroneously made members of the Employee and Partner Manager
groups.
+ some cleanup in the context management
bzr revid: odo@openerp.com-20120731143203-pv4jbn4dh99pz0v3
- Support inconsistent encoding specifications in
mail bodies with crashing
- Mark messages as seen on IMAP servers only when they
have actually been processed
- Properly commit after each incoming message, avoiding
global rollback in case of later failure (during
fetchmail cron task)
- Avoid crashing when importing mail without a proper
From header
Note: this fix depends on a corresponding server fix
(revno: 4248
rev-id: odo@openerp.com-20120727134402-vafp3wqlwnjsxntk)
bzr revid: odo@openerp.com-20120727150051-e1q0m92tyrazz82f
By giving control on the error handling in
tool.ustr(), we let the caller decide what
should happen with invalid characters.
e.g. with errors="replace", all invalid
characters will be replaced by the UTF-8
question-mark character U+FFFD.
bzr revid: odo@openerp.com-20120727145941-7svyvsyvrtlhzkd0
- Support inconsistent encoding specifications in
mail bodies with crashing
- Mark messages as seen on IMAP servers only when they
have actually been processed
- Properly commit after each incoming message, avoiding
global rollback in case of later failure (during
fetchmail cron task)
- Avoid crashing when importing mail without a proper
From header
Note: this fix depends on a corresponding server fix
(revno: 4248
rev-id: odo@openerp.com-20120727134402-vafp3wqlwnjsxntk)
bzr revid: odo@openerp.com-20120727135007-awudey1lkqtzoaot
By giving control on the error handling in
tool.ustr(), we let the caller decide what
should happen with invalid characters.
e.g. with errors="replace", all invalid
characters will be replaced by the UTF-8
question-mark character U+FFFD.
bzr revid: odo@openerp.com-20120727134402-vafp3wqlwnjsxntk
read_group does not respect "Next Partner Entries to reconcile" where
search is overridden to.
=> read_group displays groups with records not available/displayed
when "Next Partner Entries to reconcile" is applied to the leaves
(and taken in account by search)
Remaining issue, the GTK client does not currently keep its context
through a read_group tree. Context values set by the search view are
only used for the base read_group, not for subsequent read_group or
search/read calls.
bzr revid: xmo@openerp.com-20120727114303-72bibeqk0xqdlpoi
Olivier Dony