PURPOSE
Currently, there is an on-change to set an activity summary to the default
summary of an activity type. This can be useful if types are properly
configured. The problem is, the activity summary will be updated even if there
isn't any default summary on the type. Meaning that it simply removing a
relevant custom summary the user might have already entered.
SPECIFICATIONS
When triggering the on-change on activity_type_id, only update the activity
summary to the default summary if there is a default summary defined on the
activity type.
LINKS
Task-2254825
PR #51373
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Bug
===
Since 0bd14547a7,
When editing a record which has a tracked field with a group, and if
the current user is not in the group, an error is raised.
Technical
=========
When we get the tracked fields, we must care about the group of the
current user and keep only the tracked fields the user have access to.
To do that, we use `fields_get`, which will return only fields accessible
by the current user group.
The method `_get_tracked_fields` is cached, but it need to depend on
the current user (and also if we are in sudo mode or not), because the
function will return different results, depending on the group of the
user.
Task-2250070
closesodoo/odoo#51915
X-original-commit: c7010058a93ca2fd3b65ac978d8333b273f04fac
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Message with type user_notification are special "invisible"
notifications that are not accessible to users normally. That's why they
were excluded from the automatic message deletion in
mail.thread.unlink(), to avoid permission errors. But this caused
orphans leftover notifications in the database, and the fix here is to
instead do the deletion of messages in sudo mode, and make sure
user_notification messages are deleted as well.
Doing this is not a security risk because the deletion of the record
itself (the super call) is still done without sudo, and if it fails,
the whole transaction will be rolled back. And it is part of the
expected ACLs for messages that if you can delete a record you are
allowed delete its messages. The fact that user_notification messages
are not accessible by normal users is for usability reasons (noise in
chatter), not security reasons.
opw-2234282
closesodoo/odoo#51010
X-original-commit: 094559aef4fdfebcba43a089cec4da5f4028a8f2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce:
- Create a second company
- Enable this company only
- Create a new company
=> Access error is raised because the `intercompany_user_id` is
OdooBot by default and OdooBot's partner cannot be read from
other companies. Hence, the company creation fails.
Like all other internal users/partners, OdooBot's partner should
be shared across companies, even if its user is inactive.
Task 2157039
See also 2390ba6
Task 2157039
closesodoo/odoo#50372
X-original-commit: 379d14d4aa7862176fb7e3f79292a1228c254aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Umbrella -> Container, easier to understand that we target a ticket / project
like model using mail.test.ticket and mail.test.container .
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Keep only mail-related tests, move odoobot in test mail full, send "update
notification" tests in mail (specific to mail). Merge some test files to
lessen number of files, perform light file renaming.
Split test mail models file to prepare some cleaning in those models and tests.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Keep only mail-related tests, move odoobot in test mail full, send "update
notification" tests in mail (specific to mail). Merge some test files to
lessen number of files, perform light file renaming.
Split test mail models file to prepare some cleaning in those models and tests.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
Many users have complained about the automated OdooBot answers like
"Pong" when the bot is pinged, that fill the chatter when the user has
the mail_bot module installed, and add no real value.
In v12, the hr module did not have a hard dependency on mail_bot, so the
users could uninstall it if they did not want/need its functionality. In
v13, mail_bot was added as a dependency to include the notification
widget and the odoobot state in the user forms modified by the hr
module. However, this also brings potentially unwanted functionality to
anyone who installs an hr related application.
This commit removes the dependency on mail_bot by adding the mail_bot_hr
bridge module, which provides integration between mail_bot and hr if
both modules are installed.
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Make aliases usage more unique, prevent re-using bounce or catchall aliases
and remove auto-uniqueness of aliases.
SPECIFICATIONS
Before this commit, user could create an email alias having same name as
catchall/bounce email alias, which should not happen. Also, while creating
or duplicating alias, if the same name was already available, a new unique
name was generated by adding a sequence number to existing name.
This behavior is not considered as a good one as it magically creates aliases
different from what user expects. User could even not own the newly-created
alias, leading to a broken mail gateway.
In this commit we improve that behavior by ensuring that no duplicate alias
name should be entered while creation / updation for both catcall/bounce and
mail alias. Also, while duplicating an alias, name will now be blank by default
to force user to enter the name. Finally when creating an alias an error is
raised if the name is already taken.
Task ID 2160070
From opw-2200219 opw-2210285 (v12)
Use case (2200219):
- Install CRM, sales and Automated Action
- Create the automated action
* Model -> Sale Order
* Trigger Condition -> On creation
* Action To Do -> Add followers
* Add Channels -> sales
- Create a new CRM opportunity with a partner set, Save
- Click on the "New quotation"
- Save
A Traceback "Error: A follower must be either a partner or
a channel (but not both)." will popup, blocking the user from
completing the action.
Use case (2210285):
After adding a channel as a follower to a sales team it is not
possible to create a sale order from a contact or opportunity. You can
only create a sale order from the sales app in that case.
End of use cases-----
This occur because the context flag default_partner_id is used by
the model to override the empty partner_id which should remain empty
Fixed in v12, forwarding the test for v13 and upward
closesodoo/odoo#48476
X-original-commit: 049aa5c2297938bcd378d1dee1aa766a646cb461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A commit merged very recently added 1 more base query to both users, but because
the count of that particular test is non deterministic, the issue is only
spotted later on runbot, and it has to be fixed now.
closesodoo/odoo#48331
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
PURPOSE
When incoming emails bounce due to alias security bounce email is quite
generic. Purpose of this task is to ease its customization and update.
SPECIFICATIONS
In order to improve the flexibility of alias, add a customizable html field
on the alias model. This html content will be send as bounce email core content
in case of bounced/unauthorized mail received for this alias,
Obviously it has no effect on 'everyone' security setting as no email will
bounce due to that issue.
If it is not set a default generic mail will be send depending on security
setting. It allows to keep void html fields when no specific bounce content
is required
In HR, an old template allowing some light customization for employee based
security option is removed as it is completely replaced by the new feature.
Also add references message-id of the mail received to the answer so that
threads are correctly set.
LINKS
Task ID 2126509
Fine tuning of 1e411e3a6d
- It moves the attachment in the message when we mark an activity as
done.
- It adds a test
OPW-2196668
closesodoo/odoo#47349
X-original-commit: 2033066426a6af6eed5f80f1bcde6e650e998f0d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the subtype data were already in the cache, by
not always reading them again.
Part of task-2180311
PR: #43841
in `message_format` and in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the notifications and tracking data were already in
the cache, by not always reading them again.
Part of task-2180311
PR: #43841
in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the attachment data were already in the cache, by
not always reading them again.
The `has_access_to_model` is removed and replaced by `sudo` because:
- from portal everything is sudo so it's pointless to check access on top of it
- from backend, it's almost impossible to trigger the case, and it's not like
returning is_main True would leak any sensitive information to an employee
Part of task-2180311
PR: #43841
It was partially tested already as part of some other performance tests, but
this new test will cover more specific cases of `message_format` and
`_message_read_dict_postprocess`.
The goal is to ensure the performances are not made worse by the following
commits, or even to be able to notice when they are made better.
Part of task-2180311
PR: #43841
Similar to what is done for the other tests, mute unnecessary log such as
`odoo.tests: skip sending email in test mode`.
Part of task-2180311
PR: #43841
When mailgateway receives an incoming email being a reply to a thread but
containing a recipient being an alias linked to another model, it is
considered as a forward to that new alias. It therefore skips the reply
step in routing and applies rules related to new thread, aka checking
all recipients.
Consider this use case: receives a email on a task from "project@domain"
project being the alias of the project which creates new tasks when not
routing replies. Reply / forward it to "project@domain, sales@domain" in
order to transfer it to the sales team (sales alias creates new leads).
As this is a forward, both aliases are evaluated, leading to a new task and a
lead which is not what we expect.
We solve this issue by removing alias linked to the ignored reply model
when considering recipients.
PR #46764
Task ID 2121551
closesodoo/odoo#46784
X-original-commit: 7cff7787cb42cc9d3d0cb4c5af41a9f09d59d1ff
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
/!\ This commit is a manual forward-port of two PR targetting originally
11.0: #40442 and its fix / partial revert #41042. /!\
Purpose of this commit is to check all recipients of incoming emails when
trying to determine the route to apply. Notably
* an incoming email should be considered as a write to catchall only if all
recipients are catchall. Catchall + a valid alias should take the alias
into account;
* an incoming email sent to the bounce alias should be considered as a bounce
even if another valid alias is in recipients and whatever the order. Indeed
it indicates an issue and bounce is considered as more important;
* forward to an alias linked to another model should check all recipients
and not only the first one. Otherwise reply_alias, forward_alias is
considered as a reply whereas it should be considered as a forward when
considering all recipients;
Tests are added according to those specifications.
Please see original PRs for more details about the content, the comments
done on it and the various discussions.
PR #46764
Task ID 2121551
X-original-commit: df00bd2d3bddf9a2b56e8554380669025e146d21
When the `select` returns nothing more than ids that are already known, there is
no need to make it at all.
This removes one query from `_read` every time it has to fetch only fields that
are stored in a different table (o2m, ...), which happens all the time when
reading a stored field first (triggering prefetch) and then reading a o2m.
The query that is now removed was used to check access rules, but the trick is
to use `check_access_rule` to verify the rules in python instead.
Part of task-2061122
closesodoo/odoo#36263
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order
as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created.
This causes duplicate entries in the mail.notification table, and can
crash when an old unique constraint is still present in that table (from
earlier Odoo versions)
To prevent this, we deduplicate the notifications and order by notification
type to get 'email' first in case the user have different notification
type ('email', 'inbox').
How to reproduce:
- Create a first user test1
- Create a second user test2
- Merge the contact test1 and test2
- Create a customer customer
- Set the user test1 as salesman
- Create a new sale.order with customer as partner
Add a test to reproduce the pathological scenario
Solution
add distinct on partner.id and order by partner.id,
users.notification_type
closesodoo/odoo#45386
X-original-commit: 00f36c60e4790c8f5341cbc4f2c67e22e6d68f87
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
The customizable "out of office" text was removed from the editable views as
part of task-2053585, but some places in the code were still using it, even
though it was never set anymore.
This commit removes the obsolete code.
Part of task-2171864
closesodoo/odoo#44968
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
How to reproduce
================
Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.
This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.
Fix
===
In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.
Task ID 2061760
PR #36845closesodoo/odoo#44765
X-original-commit: e94349ed65e05a40af6e690e366de81fc5aa6725
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
This commit prevents sending a notification within Odoo when a
message is posted from a mailing channel to a user whose notification
management preference is set to "Handle by Emails".
Task-ID 2033302
closesodoo/odoo#36000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
Purpose
=======
Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist
closesodoo/odoo#43830
Taskid: 2176445
X-original-commit: 82d2d581a2590a9c782cbc71b5005a4198b70d77
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit 976e560a87.
Even if it didn't looked like a bad idea, this need some more thinking.
This new version of query count creates random failure of runbot builds.
closesodoo/odoo#43820
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Query counts weren't adapted to recent performance changes.
This commit updates the different query counts to make sure
any commit changing the query counts knows it and does it on purpose.
Some query counts may vary between community and enterprise
and therefore have a higher value than needed in community version.
closesodoo/odoo#43202
Related: odoo/enterprise#7682
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Revision on https://github.com/odoo/odoo/commit/a55c78836f172dba1cfa6db3df0e927a9c7e6471
Before this commit, marking all messages as read from Discuss inbox
did not update the UI correctly, hence requiring a page reload.
This bug comes from a typo in the commit above, which passed a list
of mail_notification instead of message ids, so that messages were
handled as marked as read by the web client.
Task-Id 2158452
closesodoo/odoo#43109
X-original-commit: 3cc03ee3db90c310dc60fe7ea18e0e6abe741ffa
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Priyanka Kakadiya