| Age | Commit message (Collapse) | Author |
|---|
|
- mode files in correct directory
- remove fetchmail_installer_view empty file, ...
|
|
|
|
Should not be necessary for the correct working of odoo (normal cron
lookup & processing is performed using raw SQL anyway).
* fixed a few ref calls just in case
* also cleaned up a few unused imports
|
|
|
|
|
|
733cb3e76f95c21db481e07c02d2af025b9d28fb
|
|
|
|
Add a 60s timeout to fetchmail connections.
Closes #7790
|
|
|
|
|
|
|
|
|
|
In order to fix Python bug https://bugs.python.org/issue16041
a maximum line length was introduced in poplib when reading
email contents from the POP3 server.
That limit is set to prevent DoS attacks via malicious POP3
servers.
The default limit (2048) seems to be too low for emails
commonly found on the internet, retrieved via POP3 from
popular mail services such as GMail, Hotmail, etc.
(The POP3 servers might send back the lines verbatim
without splitting them up)
This is discussed in follow-up Python bug
https://bugs.python.org/issue23906.
Workaround implemented by forcing a higher default limit
to accomodate POP3 responses with lines up to 64KB.
|
|
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
|
|
|
|
|
|
|
|
Most pop servers don't perform deletions until QUIT. If for some reason
the process is killed while fetching a large quantity of messages, the
quit method isn't invoked, while the commit method has been. We may thus
end up with duplicated messages the next time we try to fetch. It therefore
helps to fetch the messages in small subsets and call the quit method between
those subsets.
|
|
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
|
|
Let 2015 be a year without modelines!
cf #4174
|
|
|
|
base_action_rules modules
Disable the the crons when they'd have nothing to do, re-enable them when a
task is (probably) introduced
|
|
|
|
|
|
In case of IMAP, the email is simply set as read but in case of POP, the email is deleted. To avoid loosing data (e.g. misconfiguration of server), the email is kept for POP.
Bug lp:1296724, opw 605667
|
|
The method does not follow naming conventions. Therefore the "guessing" api
decorator picks the wrong method wrapper.
(Manual rebase of #1003)
|
|
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
|
|
|
|
revid:dle@openerp.com-20140217124044-o8sgz1esfqeha01f
bzr revid: dle@openerp.com-20140214100922-m6rf7c6x85nv67sl
bzr revid: dle@openerp.com-20140214114713-oab4kbearvv7g3nh
bzr revid: dle@openerp.com-20140214131810-9abebxpfeoga1crn
bzr revid: dle@openerp.com-20140217124230-ov201kfep88f5tn7
|
|
Notably, do not discard the whole email stack or stop after first crashed email processing.
Featuring:
- [FORWARD] [FIX] Forward port of revision 6920 of 6.1 addons branch, revid:odo@openerp.com-20120727150051-e1q0m92tyrazz82f. Purpose: some fixes and more robuts handling of incoming emails
- [IMP] mail: mail_thread: message routing: raise exceptions instead of using asserts. Indeed assert are statements meant to be used when developping, for debug purpose. In a production environment it is safer to use real exceptions that can be managed accordingly.
- [FIX] mail: fixed tests, no more AssertionError, but ValueError
- [IMP] fetchmail: try / except each email processing. This allows to print an exception in the logs for every failed email processing, without crashing the whole stack. Any failed or succeeded email is set as seen, to avoid crashing every time the scheduler runs.
bzr revid: tde@openerp.com-20140213115922-33vxgj7nfy86ashw
|
|
bzr revid: tde@openerp.com-20140213112946-i351aazw4r2ezfz4
|
|
found during processing. This way, all emails in the queue are managed and
all failed emails have their own exception in the logs, allowing easier
debugging.
Note that a failed email is set as seen to avoid processing it every time
the scheduler runs.
bzr revid: tde@openerp.com-20140213095717-tcwgkl143i3ujw8h
|
|
Revid: revid:odo@openerp.com-20120727150051-e1q0m92tyrazz82f
Purpose: some fixes and more robuts handling of incoming emails
bzr revid: tde@openerp.com-20140212160857-s889npk2q133xvy2
|
|
bzr revid: tde@openerp.com-20130411124446-73gzyw3eo925w3dv
|
|
bzr revid: al@openerp.com-20130405030026-oltyhb537w3p273g
|
|
enable a 3 micro hz cron only if needed as we want to lower the maximum
cron frequency in default addons to 1 micro hz
bzr revid: al@openerp.com-20130405024213-ll6t26j685rati5a
|
|
bzr revid: vmt@openerp.com-20130322134958-jhe6m0222jq7wo41
|
|
bzr revid: al@openerp.com-20130225145859-etxj4hetsnznd1aa
|
|
bzr revid: vmt@openerp.com-20130222161029-zecwro75yra2vz0d
|
|
bzr revid: vmt@openerp.com-20121210111654-0pm3pupnqqeip52n
|
|
bzr revid: odo@openerp.com-20121206153856-9y9v8ok6yxo6l5f0
|
|
bzr revid: vmt@openerp.com-20121206145632-0h1coh5aaem65wsy
|
|
bzr revid: tde@openerp.com-20121108160826-40dj27zvmqxf4im7
|
|
bzr revid: fp@tinyerp.com-20120930124920-otcsuf4kgzf4wl31
|
|
bzr revid: tta@openerp.com-20120927072349-wlkyow2py4969gtb
|
|
bzr revid: odo@openerp.com-20120821210953-olzgm14wsk7jzcia
|
|
bzr revid: tde@openerp.com-20120820130631-3kn57wnvj4ssyrjt
|
|
bzr revid: odo@openerp.com-20120814082029-i1b7d4l5cqgs434g
|
|
bzr revid: odo@openerp.com-20120807180412-u2gdsjg579ak7zxp
|
|
also replace the error message title 'Operation Not Permitted' by 'Invalid Action'
bzr revid: abo@openerp.com-20120807120451-zdrrecilfh82obhl
|
