Frequents calls to list.remove() were being a bottleneck for large
document lists (100k+). Using a set make remove() calls much faster.
Also turned a read() into a pure SQL command, as its high-level
features were unnecessary (security checks performed before and
after it anyways) and it was 50% slower than the direct SQL version.
This commit has a corresponding addons patch in order to use a set
instead of a list in the document module as well.
bzr revid: odo@openerp.com-20120821130202-71z83drt347lf45n
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
The API for sending emails has changed in 6.1, use the new one.
Also fix the expired contract filter to behave similarly to the
"Contracts To Renew" menu inside OpenERP.
bzr revid: odo@openerp.com-20120725160807-xzngv988dso9z6zj
Olivier Dony