Prepares the move of ICP to mail before replacing them by dynamic alias
domains. Improve test coverage, notably for edge cases. Continue to make
tests more explicit after odoo/odoo#131492. Some tests are also merged to
lessen number of different tests when possible, notably when only a test
parameter differs (like giving an SMTP session or not).
Clean ICP and mail servers setup in test classes allowing to remove some
unnecessary extra initialization. Cleanup a mock in mail.
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130750
Before this commit, when the user tries to access to activity view,
a traceback is occurred because `ctx.__comp__.evaluateBooleanExpr`
is not a function used inside the template of `ActivityRecord`.
That function is in fact used in the view compiler but the
ActivityRecord component does not have that function defined.
This commit defines that function in `ActivityRecord` component to
correctly compile its template.
Steps to reproduce:
------------------
1. Install Project
2. Go to Project > Tasks > My Tasks
3. Select the activity view of `project.task`
Actual behavior:
---------------
A traceback is occurred saying `ctx.__comp__.evaluateBooleanExpr`
is not a function.
Expected behavior:
-----------------
The activity view should be loaded as before.
closesodoo/odoo#132610
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
* = account, calendar, im_livechat, mrp, project_todo, sms, snailmail,
test_mail, web, website_livechat
`contains` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
closesodoo/odoo#130451
Related: odoo/enterprise#44999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This field is mainly used for record rules. We want to be sure that
changes in the _search method don't crash the logic.
Related PR: https://github.com/odoo/odoo/pull/121561
TT43572
closesodoo/odoo#132441
X-original-commit: fe07c6b405c536171cafa3c5a9e05a31049dd7ad
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some external tools send email as pure html (no multipart) and when
parsing such email we ends up having the raw HTML as body (text)
This commit ensure we correctly parse and sanitize the body as HTML
for such emails.
closesodoo/odoo#132127
Task-id: 3451889
X-original-commit: a4763d214bfc7b09510226e552f749f9cd95870e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
RATIONALE
This prepares the move of ICP to mail before replacing them by dynamic alias
domains.
Cleanup tests: try to use loops with input / expected to better understand
the various test cases, add some comments, improve logs when failing to
find the right sent email. Rename tests to have a better test structure
when reading logs.
Remove a test from odoo/odoo@3b6c20805c that adds nothing except testing
the test suite.
OTHER ADDONS
In test_mail: have a specific class for testing servers as other data is
not necessary, and it allows to have a tag for it.
In mass mailing: concatenate test about server finding, several tests can be
done in a single unit test.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#131492
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In future commit, we plan to use it notably to remove custom code in account
journal model and make it more standard. Using it in more models will be done
later, but it is a candidate to cleanup unused aliases related to discuss
channel model.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Linking some bug fixes about that subject (notably due to 'account.journal'
model that uses aliases without going through the 'mail.alias.mixin', hence
allowing to see differences between sanitize and constraint):
* odoo/odoo@33bd1a951a : non ascii aliases when installing COA and generating
journals automatic email aliases;
* odoo/odoo@e08ee893d1 : left-part should not begin or end with dots as well
as containing dots sequence;
* odoo/odoo@f1215389e8 : prevent international char in aliases;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently ICP parameter clean and check is done at create / write override.
However it should be done at ``set_param`` level to avoid messing with the
specific behavior of ir.config_parameter with falsy values.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
In addition to checking conflicts with existing aliases, we have to check
that given name list also contains only unique names. Otherwise creating
in batch with duplicates raises the SQL unicity constraint instead of the
expected UserError.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Aliases should be unique except when they are empty. Indeed each valid email
address should be unique, as it targets a specific behavior e.g. creating
a task in a project or a ticket in an helpdesk team.
For that purpose an SQL constraint exists that enforces the unicity. Null
values in DB are not considered as being the same, meaning we may have
multiples aliases with Null values in DB.
When voiding the alias we may end up with a void string, which is not the
same as giving False to the ORM in term of DB storage. Multiple void strings
break the unicity constraint where multiple False strings do not.
In this commit we therefore enforce that void alias names are forced to
False to avoid any constraint issue. Sanitize method is now independent
from the check method, to avoid calling multiple times the sanitization
as it is often used for other checks.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
CODE LINT / CLEANUP
Reorder fields definition per main usage: definition, owner, parent, gateway
configuration. Order computed fields accordingly.
Rename some methods (notably constrains), move an inner sanitize method as a
model method to allow its future usage.
Perfom a quick linting of code, simplify some lines.
TESTS
Add some tests related to alias management, notably copy, and multi-company
models using aliases. Those will help when moving to multi-company support
for aliases.
Add tests for current sanitation / cleaning of alias names and alias domain
parameters, to be more precise about accepted / unallowed characters, support
of unicode, ...
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
With this commit, users can send voice messages in channels and chat.
There's a new button in composer to record audio from the microphone,
up to 1 minute clip duration. This adds a voice attachment with its
dedicated voice player that shows waveforms and allows playback.
To ensure compatibility in all supported browsers, we choose to
encode voice recording with `audio/mp3` thanks to lib `lamejs`.
Task-3240168
closesodoo/odoo#117036
Related: odoo/enterprise#45482
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
[1] introduces an issue when a response is sent to an aliased email.
In that case, it is intended that the message should be created
by the owner of the alias by [2]
Which breaks the assumption of made in the first commit, as the message
is being passively processed by fetchmail.
This causes the owner of the alias to never be notified on reponses
in cases where the message could be an alias update.
i.e. on any model where the alias applies.
Because the responses are assumed to have been authored by the owner.
As we do not actually care who creates the message records
and deciding the alias owner 'created the message' does not
actually make sense.
We make sure messages are created by odoobot even
if the message was sent to an alias address.
[1]: c676ed3ea906e99d27a6116cd77218c5ec95b416
[2]: af80c68ae5
task-3383275
X-original-commit: 96fe37d37c94c3d6f4642bd6c28d13fcd87075b7
Part-of: odoo/odoo#130798
Rename alias domain and aliases used a test data. This allows to make
them easier to read, follow, grep and understand.
Activate multi-company on alias and gateway tests, ensuring it currently
has few impact on tests.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
Move alias-specific tests in their own file. This model deserves its own
test file containing unit tests for both alias model and alias mixin. This
helps improving and debugging the model, instead of having them mixed with
gateway-specific tests.
Activate multi-company in setup, preparing multi-company support for aliases
and alias domains.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
In addition to finding the customer, sometimes we just want any partner on
a record, notably for VOIP. For that purpose we improve heuristic for
finding partner (fields or records). It introspects the model to find any
relational field towards res.partner. Note that as it is generic it does
not ensure the partner is a customer, just some partner.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
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
Sébastien Theys