Now that most of the webclient codebase (fields, views, client
actions...) has been converted to owl, the legacy extra next tick
used in a lot of tests is no longer necessary. This commit removes
the helper and its usage. At some places, a real tick was needed,
but we didn't see it because of the use of the legacy extra next
tick.
Part of task~3439226
closesodoo/odoo#130236
Related: odoo/enterprise#44869
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
luxon and moment are both used in the solution,
but these two libraries facilitate the manipulation
of dates. It was decided to replace all uses of
moment with luxon so we can then remove
moment.js from the code and lighten the assets.
task-3391739
closesodoo/odoo#128752
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
* = crm,hr_work_entry_holidays
This commit changes the value of the "QueryCount" as `mail_enterprise`
executes a new query to search for devices associated with the partner.
Task ID: 3123678
closesodoo/odoo#127198
Related: odoo/enterprise#43577
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit implements a mixin, `MailTrackingDurationMixin`, that can be added
to a model with a `many2one` field. It computes the time a record spends in each
value the many2one field takes and stores it in a JSON field
(`duration_tracking`).
The primary use is with the StatusBarDurationField
(`widget='statusbar_duration'`), to compute and display the time a record has
spent in each stage in the form view statusbar.
To specify on what field the computation has to be done, the model that inherits
from this mixin has to specify `_track_duration_field`. (e.g.
_track_duration_field = 'stage_id')
Computation is based on `mail.tracking.value` messages, so tracking has to be
activated for that field.
Task-3032773
Part-of: odoo/odoo#108554
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
luxon and moment are both used in the solution, but
these two libraries facilitate the manipulation of dates.
It was decided to replace all uses of moment with
luxon so we can then remove moment.js from the
code and lighten the assets.
task-3391739
closesodoo/odoo#127406
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Steps to reproduce:
- Install CRM and Helpdesk modules (for test purposes)
- Set a custom alias domain (e.g. "mydomain.com")
- Go to CRM > Configuration > Sales Teams
- Check that a team has en email Alias (e.g. "info@mydomain.com")
- Go to Helpdesk > Configuration > Helpdesk Teams
- Check that a team has en email Alias (e.g. "support@mydomain.com")
- Email your instance with the following `to` value:
info@mydomain.com, support@test.com
(notice second email does not match the DB alias domain)
- Go to CRM : A task has been created
- Go to Helpdesk : A ticket has been created
Issue:
The ticket in Helpdesk should not have been created.
Cause:
The message_route method does not check the domain of the email
address before creating the routes.
Solution:
If `mail.catchall.domain.allowed` system parameter is set, filter to
only keep the emails address that match the allowed domains (including
domain set in `mail.catchall.domain` system parameter).
The value of `mail.catchall.domain.allowed` system parameter should
be a comma separated list of domains. e.g. `example.com,example.org`
opw-3150972
closesodoo/odoo#128346
X-original-commit: 5b73428104789433fd65431f7631a2e9eb863b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, only logged notes could be edited in chatter.
With this commit, messages sent with "Send message" are also
editable.
Task-3380465
closesodoo/odoo#125939
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior this commit:
In mail subtype, any users could have perform modification on it.
After this commit:
Now user have only access to read and only admin can do all the modifications.
Task-3245940
closesodoo/odoo#127539
X-original-commit: 1b99f9b6608793612dda72007a4ca2258373a97f
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
This commit fixes the display of the ColumnProgress component, which was
no longer displaying an animation when a filter is applied. This was due
to changes made in commit (1), introducing an "activeBar" key on the
value given to the ColumnProgress component.
A test has been modified to assert that the classes corresponding to the
animation are added as expected when a filter is selected.
1) 58ca40b032closesodoo/odoo#124969
X-original-commit: b4857a5c4570d3824b581003cdf456bcdc29f75f
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
odoo/odoo#122354 added this test but didn't handle that other models
might trigger systray activities.
On June 12th, the test started failing because calendar has a "Pricing
Discussion" demo calendar event on the 12th of every month. It
probably would have also failed on the 3rd and 22nd which both have
demo meetings for the admin.
Fix by looking up specifically activities of the test model we're
concerned with.
closesodoo/odoo#124684
X-original-commit: 54dce61ef8fa97e18f0cf53d1f098af55e1210e9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Remove "fake" feature sub-folders that make files harder to find.
Note: If there are too many files in the main folder now, a new split
that actually makes sense can be done at a later time: this would not
just be code move, but removing coupling between said feature and the
rest of the code.
Apply consistent structure, where the top level folder is a feature (or
core), and sub-folders are subdivision of the feature depending on
context (closely related to assets bundles).
```
- core
- common
- public
- web
- feature
- common
- public
- web
```
The opportunity is taken to reorganize the top of the files and imports:
- Always use absolute path in imports to be able to find all usages of a
file with a single search.
- Reorganize imports to group them by module, and to sort them
alphabetically by path/feature.
- Always use single asterisk (*) for `odoo-module`: less characters yay!
And double asterisk should be used for JSDoc comments, not for custom
instructions.
Part of task-3265211
closesodoo/odoo#124168
Related: odoo/enterprise#42121
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit fixes issues that could happen when a groupBy is present
in the load params from the ActivityModel. Before the rewrite of the
view to Owl, this code was present but was forgotten. This causes
crashes whenever web_search_read is then called, leading to undefined
record in the template, and crashing the view.
Now, the groupBy param (if present) is replaced by an empty array.
A test has been added to verify that during the load, even if the
ActivityModel has received a groupBy in its load parameters.
closesodoo/odoo#124215
X-original-commit: b6fa8ec174f5467baaed32b0c12acd0224757281
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Before this commit, when hr was installed and Demo clicks on avatar
of Mitchell Admin, open chat failed due to access right exception.
This happens because open chat works only with internal users, and
when we don't know whether the partner has an internal user, we have
to check whether there's a user linked to this partner.
Doing `searchRead()` without passing any field triggers this missing
access right for some reasons.
Only the knowledge of an existing `userId` is enough, so we
can actually just make a `search()` to get the user id. This won't
trigger the access right exception while giving the user id of
the partner if this exists, thus proceeding with open chat request.
closesodoo/odoo#123796
X-original-commit: 2f6dc5f4222d380cf77c6660ccce8b7381e0e64a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
There exists edge case on `reply_model`. when value of
`mail_messages.model` in database is empty then `mail_messages.model`
returns False, hence `reply_model` becomes False which raises
an error because _get_id does not accept a falsy values.
(because query: `SELECT id FROM ir_model WHERE model=false` has to
be run and model is char). Because of the fact that this query never
runs and fails opportunity is lost.
task-3248489
closesodoo/odoo#123488
X-original-commit: 6c0d2d7a9d44459f3e09a38bd80ef9b018e8c946
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).
Part of task-3266643
closesodoo/odoo#123070
X-original-commit: 9dd7ae942aebe2cfd3e2dcd52e10b3bff5c8e0a9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
At present the user can select an option in the settings to check VAT
numbers against the VIES system. If the VAT number fails this
validation the result is a non-blocking banner message that informs the
user that the VIES validation has failed, but has no further
ramifications (the user can still use an unrecognised VAT number).
This non-blocking functionality is still desirable, however we wish to
determine the validity of certain fiscal positions based on whether the
VIES VAT check is valid.
In order to acheive this, the computed boolean `vies_valid` field is
added, and populated based on the results when comparing the VAT against
the VIES system. It depends on the `vat` and `country_id` of the
partner. If it looks like the VIES check needs to be performed on this
vat and if any company in the db requires a VIES vat check, the check is
performed, and if none do, then check is not performed. The field can be
manually edited, but is also tracked.
Provided we know whether a partner has a valid VIES vat or not, it is
only important sometimes in trying to find the appropriate fiscal
position (because VIES is only confirms validity of a VAT number for
intra-community trade). Because of this, a computed boolean field
called `perform_vies_validation` is added to represent this on the
partner. For example if a partner is from the same country as the
current company, then it doesn't matter that it's VIES valid or not, all
that matters is that there is some string in its vat field for the "VAT
Required" to be satsified, so the `perform_vies_validation` field would
be False. This field is also used to determine whether the `vies_valid`
checkbox should be shown or hidden on the partner form view.
A hook called _get_vat_valid is placed in the method on fiscal position
that retrieves the appropriate fiscal position for a given account move,
and it is overridden by a function in base_vat, which specifies whether
the partner/delivery address matches the 'vat_required' condition when
VIES validity is relevant for the company/partner (see the above
`perform_vies_validation` field).
`sale_stock` and `test_mail` performance tests are updated in order to
account for the additional queries introduced in the _get_vat_required
hook (in fetching the base.europe country ids) and the
_compute_vies_valid respectively.
closesodoo/odoo#116391
Task-id: 3218194
Related: odoo/upgrade#4498
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose
=======
Like standard avatar widget, we want to open the chat window of a user
when clicking on a many2many / many2one avatar property.
Task-3208449
Part-of: odoo/odoo#114200
Purpose is to improve the depth of 'message_format' performance tests by being
multirecords-enabled, in addition to being multimessages enabled. We also add
more 2many fields in order to better see their effect (notably link previews
and reactions, recently added).
Task-3322905
Part-of: odoo/odoo#121104
Update counters to match current runbot state. Several changes (ORM, mail
code organization) lead to some counters being obsolete.
Task-3322905
Part-of: odoo/odoo#121104
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.
1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.
NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67)
when decoding the attachment.
2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).
3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.
4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.
opw-3144519
opw-3149649
closesodoo/odoo#121076
X-original-commit: 1e193a92b9c84e75b958985f8067873b90f686e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Add tests that check the behavior of unfollowing a record from the inbox and
the unfollow link in email.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method. We also add a test checking that internal user can unsubscribe a
record without any read and write rights. And that a portal user can't in the
same circumstance.
Task-3061864
Part-of: odoo/odoo#107978
In order to display the unfollow link or not in emails or in the inbox, the
system need to query the followers of the document. This is what explains the
added queries.
See odoo/odoo#107978
Task-3061864
Before this commit, tests were using current date to make assertion.
It's best to avoid making tests that use current date, as it might
fail when run at specific time (e.g. at midnight or during holidays).
closesodoo/odoo#120800
X-original-commit: 5bcef0f1d6ab48e408bc5058ea90d85f96da8928
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit simply fixes how the activity renderer propagates the
group.progressValue prop to the ColumnProgress component so that
the active value is only set for the filtered column and not for every
column.
opw-3272571
closesodoo/odoo#120733
X-original-commit: 3bd539913e9ca6f9db9bb55caaa4a85b69a912e0
Signed-off-by: Luca Vitali <luvi@odoo.com>
The activity view is an aggregation view, meaning that we show all the
activies with no limit of records.
Steps to reproduce:
There is no easy way to reproduce the bug, the database should be
populated with more than 80 records in a model and have an activity
planned for the 81th record.
Current Behaviour:
The Activity view loads all the activities without limit and so the
activity for the 81th record. The problem is that the 81th record does
not have been loaded due to the default limit of the RelationaLModel.
Therefore the activity view crash because it cannot fetch the missing
record for a loaded activity.
Expected Behaviour:
The activity view laods all the activities but also loads all the
records so it can render them.
closesodoo/odoo#120654
X-original-commit: 885c7bb33a3cb25962c090290e6b27bc11a71f41
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
This commit introduces a date picker OWL component meant to handle the
following use-cases:
- date picker
- date & time picker
- date range picker
- date & time range picker
Basically, this component is the union of the two previous third-party
libraries handling these cases: TempusDominus and DateRangePicker.
New components introduced:
* The main addition of this commit is the `DateTimePicker` itself which
handles the display and interactions of the calendar and time pickers.
> see @web/core/datetime/datetime_picker
* The picker can then be coupled to an input using the
`useDateTimePicker` hook. The purpose of this hook is to handle events
on a given input element and syncronize its value to a date picker it
will spawn in a popover.
> see @web/core/datetime/datetime_hook
* Lastly, a simple `DateTimeInput` component will render an input and
call the hook mentioned above to handle it. This component is
effectively replacing the previous DatePicker and DateTimePicker
components (note that it does not handle range values).
> see @web/core/datetime/datetime_input
Another noticeable change of this commit is the definition of daterange
fields in views:
- Previously, the arch would have to define both fields
and bind them via their options, while also adding an arrow between
inputs or other forms of connection.
- In the new implementation, only the start date field must be declared,
and a date range can be spawned by providing an `end_date_field` in its
options.
Example:
```xml
<field
name="start_datetime"
widget="daterange"
options="{'end_date_field': 'end_datetime'}"
/>
```
warning Added limitations:
- this new way of declaring date ranges means that templates have been
revised to declare one field tag instead of two. This means that list
views using date ranges have lost the ability to be sorted on their end
date fields.
> Justification: the current use cases have been reviewed and it has
been decided that it was not needed to sort on the end date on the
affected list views.
> Workaround: drop the date range and declare both fields as simple date
pickers (i.e. without the end_date_field option).
- all modifiers applied to a field using a date range will be copied and
applied to the end date field. There is no way to define modifiers
specific to one field or the other.
> Justification: there was no use case where one of the two fields
needed specific modifiers.
> Workaround: same as the previous point: split the range into 2 simple
date picker fields.
Additional notes:
- the widget="daterange" is not mandatory in form views, but is required
in list views because only fields with explicit widgets will not be
rendered as simple <span> elements. The date range feature will be
available as soon as an end_date_field is specified.
- as the end date field is not explicitly defined in the view anymore,
any modifier depending on it need to have it defined as invisible
somewhere in the arch.
Task ID: 3121497
Part-of: odoo/odoo#112171
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Pierre Pulinckx <pipu@odoo.com>
Currently some auto_reply templates are internal as a means to prevent
notifying users everytime we send a reply to somebody.
This raises the issue that since responses to internal notifications
are themselves internal notifications, often nobody will be notified of
responses to these automated messages.
We fix this by marking these messages as auto_comments, which will
ensure responses to these messages are
considered non-internal (and thus 'discussions', by default).
task-2834304
closesodoo/odoo#94018
Related: odoo/enterprise#35466
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a tracked value sent a mail template on creation of a record,
the template was displayed before the original message in the chatter.
We fix this by using precommit hooks similar to those already used for
tracking.
We also update the query count for a couple of tests. This is required
because in those tests the test user is not in the cache when we execute
the precommit hook, which we use to fetch a fallback language early in
the precommit.
Task-2834304
Part-of: odoo/odoo#94018
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
A new `_track_set_author` method is now available to explicitly set the
author of the tracking messages.
Related Enterprise PR: odoo/enterprise#38986closesodoo/odoo#117073
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Configure incoming mail server and set it to create X record
on incoming mails (X can be any model with a chatter)
- Create a CSV file and set the encoding to UTF-16
- Send the CSV file through Gmail to the Odoo instance
- Go to model X and open the created record
- In the chatter, click/download the CSV file
- Open the downloaded file with Geany (or any file editor that can
show the file encoding)
Issue:
The file encoding is not the same as the original file (utf-8 instead
of utf-16).
Working with Outlook.
Cause:
The difference between Outlook and Gmail is that Gmail provides the
charset of the file.
The content of the mail is retrieved using `email` python lib.
The lib will try to retrieve the charset of the file and fallback
on `ASCII` if not available, then return the decode content.
```python
def get_text_content(msg, errors='replace'):
content = msg.get_payload(decode=True)
charset = msg.get_param('charset', 'ASCII')
return content.decode(charset, errors=errors)
```
Example:
content = b'd\x00a\x00,\x00,\x00,\......'
Outlook:
charset = 'ASCII'
return => 'd\x00a\x00,\x00,\x00...'
Gmail:
charset = 'UTF-16LE'
return => 'da,,,,,\n,,,,,\....'
In the post process of the attachment, the content is encoded in
'utf-8' (to then encoded in base64) before creating the attachment
record.
Content encoded to 'utf-8':
Outlook: b'd\x00a\x00,\x00,\x00...'
Gmail: b'da,,,,,\n,,,,,\n....'
Therefore, when writing the file on the disk, the encoding is based
on the binary content.
Solution:
When parsing the mail, add the encoding charset to the `info` variable.
Then, when creating the attachment, use the charset in `info` (or
fallback on 'utf'8' if no charset set) to encode the content.
opw-3089009
closesodoo/odoo#118694
X-original-commit: 2d1b13e68d8bb204ecfe12a9d3db519c4264592c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Before this, the resource_ref field is computed once in the default_get.
This means if the cache is invalidated, its value is unrecoverable.
Notably, the cache is invalidated when an attachment is generated
(triggering a commit).
So calling _generate_template could invalidate resource_ref,
which we use as a key to retrieve its result.
This results in a traceback for the user when trying to preview
a template where the first record hasn't yet generated its attachment.
As an example, trying to preview `Sales: Send Quotation`
on fresh installs.
task-3162320
X-original-commit: b4bd93c9b61736a7f41d70afe5db977a6e4b35e0
Part-of: odoo/odoo#118710
If the preview wizard was used to preview a template on a model that
has no record, error_msg would not be set.
This means the field is never set in that case and creating the wizard
results in a cache miss on that field.
The fix is to simply set it, and we add a test to cover that flow of
the wizard.
task-3162320
X-original-commit: 0976ce53e0a97a1f49dc2a262cf66355242fde25
Part-of: odoo/odoo#118710
Always apply the blacklist in mass_mail composition mode regardless of the
recipient model implementing mail.thread.blacklist or not.
This solves the problem of mail sent to black listed address for model not
inheriting from mail.thread.blacklist.
Technical notes:
- it has been done in mail.compose.message _get_blacklist_record_ids ignoring
the mixin mail.thread.blacklist to avoid model change in stable.
- some tests have one added query because the blacklist is now queried for each
batch mail sends even if the model of the recipient doesn't implement
mail.thread.blacklist.
Task-2834862
closesodoo/odoo#118497
X-original-commit: 263e86114c60650f421354e165364afcd4122461
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1], a unique id is used for fieldNodes, therefore, the code to
keep track of last update images on the activity view needs to change
also.
Before this commit, we search the write_date on the fieldModes using the
id, and if it's not present, a new one is created using as id
"write_date".
Now, as a unique id is needed, we search using the name, and if it's not
present, a new one is created using as id "write_date_0".
Note that this is already the behavior on kanbanParse.
[1]: https://github.com/odoo/odoo/commit/baebb6a5b05ac8d59501a6071a5513e31a4ca047closesodoo/odoo#118320
Signed-off-by: Luca Vitali <luvi@odoo.com>
When using the composer on a non-thread model a notification is sent instead
of posting a message, as the model does not support the posting process.
However there is currently a crash due to the default subject computation
which is solved in this commit.
Task-3254379
Part-of: odoo/odoo#117763
While we run cron `Data Merge: Find Duplicate Records` an issue raises because
`data_merge.model` has no method `_message_compute_subject`. Indeed it is
possible to notify on non-thread models but that method is a thread-only
method.
In this commit, we only call `_message_compute_subject` when it's available
in model.
sentry-3947126655
Task-3254379
Part-of: odoo/odoo#117763
'TestMailCommon' was useless and is replaced by the 'MailCommon' class defined
directly in Mail addon, easing inheritance and imports.
Task-3263512
Part-of: odoo/odoo#117606
Steps to reproduce:
- Install l10n_mx modules
- Switch to MX company
- Create invoice and confirm it
- Send it to PAC in test environment (Process Now button)
- Click Send & Print button
Issue:
- XML Preview does not display, only shows the file name in the top right corner of the chatter.
Cause:
In l10n_mx_edi, when posting the invoice, the only attachment available is the xml sent to the government in `_message_set_main_attachment_id`.
Therefore the xml is set as the main attachment.
When clicking on "Send and Print", the pdf is generated but the main attachment is still the xml
Solution:
Redefine the main attachment everytime the the main attachment is an xml
Note:
- octet-stream have also been filtered out
opw-3085934
closesodoo/odoo#116784
X-original-commit: 48e6e81a47f5371f5985d135e56f39f445eb2854
Related: odoo/enterprise#38861
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a test that check recipients displayed in the template preview. This test
has been added following the fix that solves the template "partner_to" not
displayed in the preview.
Task-3196081
X-original-commit: 86a492275e56217a5edd57d99a0db7576aa91377
Part-of: odoo/odoo#116431
Aaron Bohy