The task will require adding new files which we don't want to do in stable. closes odoo/odoo#58875 X-original-commit: 5580a0e4e44744d13ec9bed03f2116c043c611b1 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
task-2280308 closes odoo/odoo#58166 X-original-commit: b63d0d2ee5f3bff24a5e1e1cd962d59bebef082d Related: odoo/enterprise#13392 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the "to followers" message inside the chatter composer was missing. Fix also some padding issue. This also restore the form dialog when you try to send a message to a suggested recipient that doesn't have a partner (someone in CC email for eg). But now, suggested recipient without partner are unchecked by default and the form open when the user try to check them. If the user discard the form dialog, the suggested recipient isn't checked. This is better since only a partner will receive a notification. task-2280157 closes odoo/odoo#58160 X-original-commit: 67d151cc36871d87b92676357a31a70de5a92fce Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The "viewer" should be the "parent" not the view itself. This distinction will become important in a future commit to allow viewers to not display the view in some situations. Rename done as a standalone commit to ease diff readability. Part of task-2310623 closes odoo/odoo#56737 X-original-commit: 1b811e6a972d72de02965adda67c5b039bee023f Related: odoo/enterprise#12756 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
task-2282334 closes odoo/odoo#56584 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The purpose of this task is to improve the UI of the 'Apps', by improving the clarity of the kanban, sequencing the apps and simplifying the app categories in the searchpanel So in this commit, Added the new sequences for ir.module.module and ir.module.category records. TaskID: 2240257 Related Enterprise: https://github.com/odoo/enterprise/pull/12413 Closes: #55907
This commit is a significant rewriting of client-side discuss, chatter, chat window, and messaging menu using OWL. The behavior should be broadly the same, with some slight functional changes here and there. From a technical standpoint, the code of messaging is mainly organized in 2 main groups of modules: - models, which are logical entities that depict the client-side state of messaging as a whole. - components, which are in charge of displaying information from models. This refactoring also introduces new JS guidelines regarding folder structure (/static) and naming rules for JS modules. Community PR: https://github.com/odoo/odoo/pull/39023 Enterprise PR: https://github.com/odoo/enterprise/pull/6249 Task-1914207 This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier, with the precious help of Lucas to speed it up towards the end. closes odoo/odoo#39023 Related: odoo/enterprise#6249 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> Co-authored-by: Alexandre Kühn <aku@odoo.com> Co-authored-by: Julien Giannone <jgi@odoo.com> Co-authored-by: Lucas Perais <lpe@odoo.com> Co-authored-by: Sébastien Theys <seb@odoo.com> Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Task ID 2265592 PR #
This widget is an extension of Many2OneAvatar, designed for many2one fields pointing to the 'res.users' model, or a model having itself a many2one field pointing to 'res.partner'. With this widget, when the avatar is clicked, we open a DM chat window with the corresponding partner. If the user clicked on itself, we open a blank chat window for the sake of consistency. In kanban views, this widget only displays the avatar. Part of task 2195254
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315