| Age | Commit message (Collapse) | Author |
|---|
|
This split responsiblilies :
- portal provides basic chatter for portal document, and
website documents (slides, blog, ...).
- website_mail provides comments moderation (unpublished mail
message)
- website_rating integrate rating when posting comments
|
|
Message are now fetched and display using javascript
to optimize performance.
Also the chatter is completely rewrite : add pager,
filter possiblity, ...
This commit is mainly technical: posting feature does
not change. Only the display with pager is new.
The goal is also to prepare frontend chatter for a
better integration with rating widget.
The mail.thread mixin is extended to manage the field
website_message_ids (display all messages that can be
seen on frontend by user (employee or not).
When fetching or posting message, a check is done to see
if we need to do it as sudo(). website_mail implement posting
messages with token or sha_in (using in website_quote).
The same verification is now done when fetching messages, via
'_special_access_object' method.
|
|
|
|
The custom check is a more complicated and slower code than using the API
method provided for that.
|
|
No functional changes, only rewrite the code with
the api.v8 which more pythonic and smooth.
|
|
- 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.
|
|
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.
|
|
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
|
|
|
|
|
|
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
|
|
first 30 characters.
|
|
chs@openerp.com-20140407144439-10n8fs6zovodwwtx
bzr revid: chs@openerp.com-20140407163318-hh3jwfkj3o2c83lk
|
|
not correct + security rule was applied on superuser
bzr revid: dle@openerp.com-20140402093721-hwcdwltbkict4oz4
|
|
on mail.message that is a short description of the message, either
the subject if present, of the beginning of the plain-text version
of the body. Used whenever messages 'subject' for all messages
is necessary.
bzr revid: tde@openerp.com-20140320151004-qq57s9r8qcpue0rs
|
|
bzr revid: odo@openerp.com-20140311155309-bs0frntkkhym8e2o
|
|
There is semantically no reason to publish old
messages, and doing so can be expensive for large
databases. Defaulting new messages to published
makes sense depending on the model on which they
are attached, so it might be better to improve
this as an opt-in handled in create() or
message_post() or via default_* context keys.
bzr revid: odo@openerp.com-20140217142006-ik18uqy9ewhhhb42
|
|
bzr revid: odo@openerp.com-20140129162532-os3lzjyf87hg1ouc
|
|
This is done to match the new module organization we want to set
for OpenERP modules. Model-related files should lie in a models
directory.
bzr revid: tde@openerp.com-20131011100057-bpe5620omyjsj0y0
|
