When writing in a discuss channel, the updated value sent to the client
should be read from the database, not directly from the values passed to
the write method.
Partially backport of https://github.com/odoo/odoo/pull/139563closesodoo/odoo#158860
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this PR, the error displayed in the public page was quite
cryptic. It was hard for the user to understand that error and even
harder to report it if needed. This PR makes the error more user
friendly.
task-3850559
closesodoo/odoo#160947
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Have two companies with helpdesk teams;
2. create a contact associated with company 1;
3. create a contact associated with company 2 w/ the same email address;
4. from this address, send an email to team 2 to create a ticket.
Issue
-----
Ticket is created using company 1's contact.
Cause
-----
When searching for partners associated with an email address, it only
looks at the first one.
Solution
--------
Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized
the current user, further prioritize based on companies matching the
records passed to `_mail_find_partner_from_email`, avoiding potential
access rights errors in multi-company environments.
Also fixes a bug in account_move where `_mail_find_partner_from_email`
was called with an `extra_domain` argument in the wrong position.
opw-3705199
closesodoo/odoo#159108
X-original-commit: 60dd5348179c9bdcc78e4ad46bd9b768a6e3ea21
Signed-off-by: Levi Siuzdak <sile@odoo.com>
When adding alias domain in v17 support of configuration parameter
was dropped. We moved from singleton configuration to multi domains
using real models.
This means most of mail support lies in mail while part of it was in base
beforehand. In some cases we want to let people do some basic
configuration using base module then install mail which could migrate
this ICP based configuration into new models. This is notably the case
with odoo.sh where mail is not always automatically installed.
Use case is: install base, do some configuration using ICP allowing notably
to setup website / server domains, main mail configuration, ... then let
people install modules on top of that configuration which generally
installs mail. With this change existing ir.config_parameters matching
pre v17 names are now used to bootstrap alias domain table at mail module
initialization.
Task-3789584
closesodoo/odoo#156654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When there is no channel members to be updated the seen status, we
should not send a notification to the channel members, otherwise it
will lead into creating a channel member with id undefined.
test case added to check that the notification is not sent when there
is no channel members to be updated.
closesodoo/odoo#156534
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
A new message type was added in stable. This is usually safe,
however in cases where there are related fields on that same selection
fetching them will raise an exception as the ORM has to fetch the translations
for the selection in DB.
We add a hack on mail.mail to update the selections in DB when fetching
the message_type field for the first time.
task-3773301
closesodoo/odoo#156235
X-original-commit: 19683173708a2b029acb4e744871772b6c248715
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Steps to reproduce:
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
closesodoo/odoo#156307
X-original-commit: d2e473f5b2b1b0fa1eae0f2a1e3698d663af07d8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Part 1: _search_is_member
-------------------------
Separate query to fetch candidate channels because the sub-select that
`_search` would generate leads psql query plan to take bad decisions.
When candidate ids are explicitly given it doesn't need to make
(incorrect) guess, at the cost of one extra but fast query.
It is expected to return hundreds of channels, a thousand at most, which
is acceptable.
A "join" would be ideal, but the ORM is currently not able to generate
it from the domain.
`sudo` is added as well because the rules for the member don't need to
be checked as no information is leaked.
Part 2: clean rules
-------------------
The rule for reading "self" is included in the rule for reading other
members. It can be disabled for "read" to avoid duplicate.
It also checked is_member again, but is_self necessarily implies it.
Part 3: clean tests
-------------------
The opportunity is taken to fix the tests. The tests where considering
as "access error" when there was an assert error inside the test (for
example not finding the channel or the member), but those needed to be
considered as failure regardless of expected outcome of access check.
Extra mute loggers are added to clean the test output.
closesodoo/odoo#153697
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
*: mail.
This PR removes the live chat sidebar category. From now on, each
channel will have its own category. This is a first step towards
providing an efficient way for operators to join/leave a live chat
channel.
part of task-3640730
closesodoo/odoo#154755
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
How to reproduce:
- Install crm with demo data
- Open the crm app
- From the menu "Configuration -> Activity Plans", create a plan
- Open a lead
- Schedule the plan just created for the lead
The log message in the chatter display due date in the wrong format:
Year(4)-month(2)-day(2) instead of the user date format (if your date format is
that one, please change it for testing).
This fixes the problem by displaying the date in the user format.
Task-3639909
closesodoo/odoo#152217
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install `crm` module (for test purpose)
- Create a new lead
- Set an email address, phone number, company name and contact name
- Save the lead
- In the chatter, send a mail (with the default recipient checked)
Issue:
- The partner has only the email address set (also set as name).
- The `contact name` on the lead is updated with the partner name
(who is the email address).
Cause:
When sending a mail with the default recipient checked, the partner
is created based only on the email address (therefore, name is same as
email), and when assigning the new partner on the lead, the
`contact name` is updated with the partner name (who is the email
address).
Solution:
Alter the route `/mail/partner/from_email` and `/mail/message/post`
so it can take or manage additional values for the creation of the
partner.
opw-3512045
closesodoo/odoo#152780
X-original-commit: 92916985b72ff1cda2021900f0aa9476f7283576
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce:
- Install contacts
- Go to any contact
- Schedule an activity on the contact by clicking on "Activities"
The flag automated of the created activity is set to True which shouldn't be
the case (you can check either in the DB or by adding the field with studio).
The same happens when scheduling plan, scheduling activities on multiple
records in the view list or a plan on multiple records.
This fixes the problem by modifying the activity schedule wizard so that it
always creates activities with automated flag set to False.
Note that that flags is used to distinguish activities created manually from
those created automatically. Some flows automatically cancel automated
activities (e.g. cancel 'validate my ticket') but those should probably not
cancel user defined activities (e.g. 'ask customer to pay'). That's why we must
ensure that activity created manually have that flag set to False.
Task-3691827
closesodoo/odoo#149965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The webclient returns a message "server error" if you add an attachment or send
a message on an archived record chatter.
steps to reproduce:
- archive a record (ex: a partner)
- send a message on the chatter or add an attachment
before this commit:
- a popup error is raised "server error"
after this commit:
- the chatter is working properly on archived records
opw-3689169
closesodoo/odoo#149862
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
When a database is miss-configured, we have no other choices to
potentially spoof the FROM. We decided that a better heuristic would
be to use the notification email instead of the user email.
Task-3645895
closesodoo/odoo#149189
X-original-commit: eae9214ade8487ac326fc83abe67af53d861e00a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The problem was the hard coded `@Mitchell Admin` in the expected result.
The case can be different when the demo data changes.
Change the test and make it fixed in all cases.
closesodoo/odoo#148710
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Mismatch of str and Markup led to escaping everything. Now properly
Markup code and escape the rest.
closesodoo/odoo#146399
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In [1], a context object was added to websocket requests to subscribe
to guests channels on cors live chats. However, the common mechanism
to subscribe to record channels is to pass a string channel that will
then be validated by the `_subscribe` method of `ir_websocket`. This
approach works with OdooSH out of the box while the other one does
not.
This PR removes the mechanism introduce in [1] in favor of the string
approach.
[1]: https://github.com/odoo/odoo/pull/130052closesodoo/odoo#147114
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The SFU is a server used to relay streaming between the participants of
a call to provide better scalability and performance than the current
peer-to-peer connections.
The required fields have been added in https://github.com/odoo/odoo/pull/138581
* `/mail/static/lib/discuss_sfu` contains the client code that is used
by the odoo client to interact with the SFU.
From: https://github.com/odoo/sfu/releases/tag/v1.0.0
* The Json Web Token code has been extracted from `web_push` while
adding support for the HS256 algorithm, to be used as the authentication
method between the SFU and Odoo.
* The python code has been updated so that the odoo server requests a
channel from the SFU when going above a participant threshold, and swap
the participants to a SFU connection afterward.
* `rtc_service.js` has been updated to support both peer-to-peer and
SFU modes.
* The `call_context_menu` has been updated to display information
relative to the SFU connection when in SFU mode.
task-2765922
closesodoo/odoo#132153
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: im_livechat.
Since 17.0, the new message separator is displayed for guests. The
`set_last_seen_message` rpc is also triggered in order to save this
information on the server side. However, the `_channel_seen` method
does not handle guests as it should.
As a consequence, the new message separator is always displayed and
the rpc call is always done when a guest loads the public page.
This PR enable guest support for this feature. Not that for live chat
channels, visitors cannot access the operators seen infos.
task-3603603
closesodoo/odoo#142546
Related: odoo/enterprise#52118
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The issue is not easy to reproduce, so the fix is not a guaranteed one.
Estimation: the click on the "send message" buttons happens too early,
and it is either doing nothing, or being immediately reset by another
action that happens at page load.
Adding a little bit of extra delay (in particular waiting for messages
to be loaded) might resolve the issue.
Also back-port code allowing to use contains in tours.
runbot-27847
closesodoo/odoo#144435
X-original-commit: 3b261b6856e935f8fe9d4e23cfddc09df8ff7fdf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Move '_create_mailing_list' as a base mass mailing tool to make it easily
usable by most mail-related test addons.
Improve '_filter_mail' tool by allowing to give an additional 'email_from'
used to filter emails produced under a mock. When having similar records
mailed several times (e.g. several mailings triggered at the same time which
may happen for marketing automation tests) it eases finding the right email
linked to a given mailing / recipient.
Improve some logs to ease debugging, notably for marketing automation.
Task-3506681 (MA: Test cleanup)
Prepares Task-2981581 (MA: Fix trace duplication and various issues)
X-original-commit: aad84dda189e13d76a87e349a7d56d84e584879c
Part-of: odoo/odoo#143088
This makes the "medium" populate of `res.users` take few seconds rather
than 2min30 on my machine.
The issue was that `write` (not in batch) is calling
`_subscribe_users_automatically` not in batch, which is particularly
slow.
`discuss_channel_nosubscribe` is removed because it was uneffective. The
condition was only on create, but the group change in
`_inverse_notification_type` was systematically triggering the
auto-subscribe outside of create anyway, which is what we want.
Part-of: odoo/odoo#142734
Before this PR cache control header for avatar was set to no-cache which is not
the right value.
This PR mark the avatar routes response as immutable when a unique string is
present. We also use the partner write_date as unique string when possible.
task-3551636
closesodoo/odoo#141326
X-original-commit: 3de4f1f1225229cbdb0512df5790ce491f04ea7e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, we used to rely on duplicates of streams and the
presence of streams to know if a session was streaming.
This commit changes this and make it so that we now use streaming
activity flags instead.
This is a prerequisite for https://github.com/odoo/odoo/pull/132153 as,
similarly to webRTC "unified plan", the SFU keeps the same streams for
the whole lifespan of a connection.
closesodoo/odoo#140053
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We do the following improvement:
- some wording changes
- the activity templates can be edited directly in the list view instead of in
a popup except in hr because sub module add too many field to be edited in
directly in the list view.
- when scheduling a plan, the due date of the created activities are computed
as the plan_date_deadline + activity type delay and if the plan_date_deadline
is not specified, as today + activity type delay.
- there were 2 res_model fields in the mail_activity_plan_view_form that was
causing a selection box to appears on many form where the model shouldn't be
selectable. We remove one of them here.
Task-3558929
Part-of: odoo/odoo#138998
Before this revision, an employee could create a discuss channel
with whatever setup he wants.
Which is fine. The critical part is for an employee to not be able
to join an existing restricted channel.
But creating a channel is not a problem.
However, he would be able to create a channel for which
he doesn't have access, meaning he creates the channel
and then no longer see it, which is not user-friendly.
closesodoo/odoo#139903
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1], guest is added to the channel immediately instead of
waiting for the guest name to be set. Since the guest is not in
the context when posting je "join" message, the author of the
message is the public user instead of the guest. This results in
an incorrect message ("public user joined the channel") since the
frontend relies on the author to set the name. This commit fixes
the issue by adding the guest to the context.
Steps to reproduce:
- Go to a channel
- Copy the invitation link
- Join the channel with this link
- The message is incorrect
[1]: https://github.com/odoo/odoo/pull/138330closesodoo/odoo#139892
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
This commit introduces a new optional feature in the chatter.
Users can request translation from the Google Cloud Translation API.
Documentation: <https://cloud.google.com/translate/docs#docs>
Adding the key in settings will instantly enable the feature for all
users of the database and consumption is not measured nor limited
by Odoo as it is natively supported using the Google Cloud Console.
Translation values are stored in the database to reduce cost as
much as possible. Therefore, translation values are automatically
garbage collected every 2 weeks to prevent database pollution.
Task-3338165
closesodoo/odoo#126555
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are used in Odoo codebase there is no usage anymore
for the old config parameters. So long and thanks for all the fish !
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from is also moved on this model, allowing an higher
level default from computation for mail servers when having knowledge of
alias domain environment. Filtering configuration based on default_from_filter
is kept as an ICP as it is mainly used for odoo-bin with smtp-host.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
Currently only base modeling and computation is done. Their usage is about to
be gradually added in mail stack.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Composer tests now use the multi-company enabled model by default, allowing to
test company-dependent behavior. This has no impact on current tests, as there
is no company-dependent fields on composer model, and all tests are anyway
run into the main company (except multi-company specific tests, suffixed
by '_mc' generally).
We therefore also add some multi-company oriented tests to check notably
return-path or environment companies in various scenarios. Go until the SMTP
generation to test mail server choice, smtp_from and filtering, notifications
email.
Followup of odoo/odoo#136318 and odoo/odoo@3ffa1a0611 notably.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
* = bus, crm_livechat, hr, mail_bot, test_discuss_full, test_mail,
website_livechat
Now that livechat uses guest, we can write proper ACL for channel and
channel member to check if the current user/guest is a member.
This allows removing most sudo in code and to simplify search domains.
Remaining sudo in discuss folder have been reviewed and commented.
task-3394829
closesodoo/odoo#138330
Related: odoo/upgrade#5295
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, an error occured when opening the discuss public
page as a non internal user. This is caused by a read rpc being done
while the user is not allowed to do it. This commit ensures this rpc
is only done when allowed.
Steps to reproduce the issue:
- Open Odoo with Mitchell Admin
- Go to a public channel
- Start a RTC call
- Join the channel as guest with the invitation link
- A pop up appears
closesodoo/odoo#139397
X-original-commit: c7e66f3878b451001dbe4e8e3cdd8ced9a8ed632
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
* = calendar,test_discuss_full, test_mail, test_mail_full
Methods can be downgraded to channel_info when called by RPC.
This increases the simplicity to use these methods in python.
closesodoo/odoo#139341
Related: odoo/enterprise#49326
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Improve link preview code
* remove useless code indirections;
* improve performance of link creation, cleanly support batch-creation (could
lead to 98+5 URLs to the same domain creation within default 10 seconds
instead of 98+1 but we feel it's ok);
* name methods according to ORM;
* use tools for html empty;
Also cleanup link preview tests: concatenate tests when possible, improve
setup, use real-life scenarios (using 'message_post' notably), remove useless
data creation.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
- Remove "channel" field in thread formatter.
- Pass `type` for all persona formatters.
- Remove some snake_case to camelCase conversions.
- Add support for inverse fields in discuss JS models.
Details:
1. [REF] mail: remove field 'channel' in thread formatter
This field was used for channel-specific fields, which made
sense when there was a dedicated Channel model that was modeled
with composition with Thread.
To simplify formatter of threads, it's best to flatten props
so that channel-specific fields are immediately available on
thread model. This will improve insertion of data with Threads.
This commit also makes the following other changes:
- remove `discuss.channel/legacy_insert` to use
`mail.record/insert` instead.
- Introduce `toData()` on record, which is helpful to have record
in data format e.g. to pass as a JSON.stringifiable object.
2. [REF] mail: slightly simplify Message.insert from notif
The handling of `mail.record/insert` for Message was handling
transition from starred non-empty message to starred empty message.
To simplify all record insert from server formatted data, the notif
data is just inserted in Message. The adjustment of starred counter
is managed at model level.
This is a prerequisite to significantly simplify all
`mail.record/insert` handling.
3. [REF] mail: rename 'res.users.settings' notifications
Before this commit, notifications related to changes of user
settings were using named notification `mail.record/insert`.
This named notification should be only used for Discuss data that
should be inserted in models. `res.users.settings` is not integrated
in Discuss model, thus it has no reason to use this named
notification.
This commit rename the notification name to `res.users.settings` for
these specific notifications. This prepares simplification on
handling any `mail.record/insert` notifications that should simply
call `Record.insert()`
4. [REF] mail: make dedicate notif for Thread/fold_state
This was using named notif "mail.record/insert", which should
be used to immediately insert data in models. This is however
a dedicated notification to imperatively manager chat window
state based on timing of receiving thread data.
This may eventually become a `mail.record/insert` in the future,
but right now it's much simpler to define it as its own named
notification, in preparation to simplify `mail.record/insert`
notifications handling.
5. [REF] mail: remove Channel in mail.record/insert
This is replaced by `Thread`, so that these data can be
immediately inserted in Thread model.
6. [REF] mail: simplify slightly Attachment.update()
Now that data containing commands is supported, we could
just assign with the command rather than destructure and pick
the dict data part.
7. [REF] mail: introduce assignIn() utils
This function helps reduce LOCs from using the "in" conditional
in sequence:
```js
if (a in data) {
this[a] = data[a];
}
if (b in data) {
this[b] = data[b];
}
if (c in data) {
this[c] = data[c];
}
```
To simply:
```js
assignIn(this, data, [a, b, c]);
```
8. [REF] mail: remove snake_case to camelCase conversion in models
They exist for the sake of keeping Python code snake_case and
JS camelCase. While it's good that each language have a community
that prefer syntax convention, when a codebase uses both languages
and they should work with the same data, it's not great to convert
snake_case to camelCase and vice-versa all the time.
Since server has authority over the data, the server chooses the
format for the keys. Most of them are snake_cased, therefore this
is usually the one we pick.
9. [REF] mail: rename Message.messageReactionGroups to Message.reactions
Easier to read, and matches relation name in JS model
10. [REF] mail: remove explicit assign of some many relations in Message
This reduce amount of custom code in insert(), in preparation to make
all models behave the same in response to inserting data.
11. [REF] mail: rename Thread.customName to Thread.channel_custom_name
To match server data field name, and avoid useless conversion in JS.
12. [REF] mail: simplify Message.insert for recipients
Have formatted data contain `type: "partner"` so it can be assigned
in relational field without adding `type: "partner"` manually in JS.
13. [REF] mail: introduce inverse field in discuss models
With this commit, fields in different models can be linked
together, so that one is mirror of the other field.
This simplifies some `onAdd`/`onDelete` that were added to
sync such fields, and this also simplifies insertion in
relational fields for discuss models that are identified
by records, such as the `MessageReactions` that is identified
by the message and the emoji.
14. [REF] mail: rename CannedResponse.name to 'source'
To make JS model and server data more alike.
15. [REF] mail: remove assignDefined in Persona model
So that eventually all model inserts use `Object.assign()`.
16. [REF] mail: remove 'last_message_id' from channel_info
At some point it was used to display last message in messaging menu.
This is already covered by `channel_fetch_preview` when opening the
messaging menu for the 1st time, so passing `last_message_id` in
channel_info is obsolete.
closesodoo/odoo#137750
Related: odoo/enterprise#48484
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
Test are updated because the wizard is opened instead of the activity form to
schedule a new activity and as the form view is only used to edit already
existing activities, default_res_id and default_res_model are no longer passed.
We defines date_deadline and date_plan_deadline in the schedule wizard because
those date are managed differently (default value, required or not, ...).
Task-3390865
Part-of: odoo/odoo#137969
Extract some test preparation, cleanup and improvements before gradually
adding features that impact tests.
Add tests about 'copy()' behavior in 'mail.alias.mixin' as it will be
impacted by multi-company enabled aliases.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138202
Before this commit, when the user shares a portal link, the receiver
has to click on the link to understand what it is about.
This commit uses new key called `preview_object` inside
`portal.frontend_layout` template.
When it is defined, it will add some useful information for the
preview link.
This commit also defines `preview_object` in portal view of project
and task to be able to have the preview link to prevent the user
from having to click on the link to understand what it is about.
task-3186692
closesodoo/odoo#113622
Related: odoo/enterprise#37514
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
Since [1], live chat visitors are using the mail guest system for
authentication. With this change, visitors are allowed to reach the
attachment upload routes (even if nothing allows it in the frontend
for now). This commit restricts attachment upload for guest and portal
users with the `allow_visitor_upload` field that can be toggled.
At the same time, this commit enables file upload when authorized
on the frontend and for cross origin live chats.
[1]: odoo#129770
task-3332628
closesodoo/odoo#137574
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Thibault Delavallée