Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
Bugs
====
On e-commerce, the portal user is not able to upload
attachment with his comment, under a product.
On website blog, the portal user is not able to upload attachment with
his comment, in the discussion of the blog.
And, in `website_crm_partner_assign`, portal user is not able to upload
attachment with his comment, under the lead/opp.
Issue
=====
In the create method of the mail message, we check is the user can
read the attachment. If he can't, we raise an error.
But, the method that make the verification doesn't care about the access
token. So, when a portal user want to upload an attachment on a "public"
record (without a token on the record to sudoed it) the error is raised.
The portal user give an token for the attachment, so he should be able
to attach it to the message. This verification is done with
`_portal_post_check_attachments` so we can sudo write the attachment
after the creation of the mail message to bypass the verification.
Task-2214795
closesodoo/odoo#51772
X-original-commit: d59f8f62dbc7771fee51c3593f89f9b6832bb7ec
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
a blog will receive notifications only for published posts. They
will not receive all comments of all posts anymore.
When commenting a post users will receive the answers.
Added tests to try to test this behavior.
