Purpose is to have a blacklist of email providers on which IAP services should
not run. Indeed those are generic mailing providers. Retrieving company
information from them makes no sense. Indeed they would be associated to the
mailing provider and not to the real company or partner using it.
In this commit we define a global domain blacklist in iap and use it in
crm_iap_lead_enrich and mail_extension, replacing existing local custom
code.
Task ID-2322455
PR #64545
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, _rpc_remote_api allows to set a timeout when calling IAP servers.
However API using this tool method does not allow to propagate it. This
renders this parameter quite useless.
This commit adds timeout optional parameter to main API methods of partner
autocomplete. Default timeout is the same as before this commit.
Task ID-2322455
PR #64545
Since odoo/enterprise@937b9214cb module
'studio_customization' has a dependency on module 'web_studio', in order
to automatically remove customizations when uninstalling 'web_studio'.
As a side effect, this marks 'studio_customization' to be upgraded when
'web_studio' is upgraded. An error is logged, but the module stays in
state `to upgrade`, thereby blocking the execution of cron jobs.
The fix simply adds an explicit (though not very elegant) condition on
the module name to filter out module 'studio_customization' when marking
modules in method `button_upgrade`.
A cleaner fix would be to use the `imported` flag, but we don't want to
risk breaking existing features in stable and will be done in master
instead.
Slightly linked to closed#43880closesodoo/odoo#64538
X-original-commit: 572e05284c1a7587e989acebd43f3c07e7e99fb1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When posting an account move before the tax lock date, Odoo will
automatically set its accounting date to the lock date + 1.
This can cause the chronology to be broken, which is not something we
want when automatically setting the date.
This will change that behavior to set the accounting date to today in
such case.
Task id #2411150closesodoo/odoo#62787
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To improve the display of tags, we are increasing slightly
the size of the line in the tag to avoid cutting the bottom of some
letters, as well as making the color of the border lighter.
Task id #2368889closesodoo/odoo#61481
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
SOC for ir.ui.view creation. If a view is created without a website_id,
it should get one if one is present in the context. Also check that
an explicit website_id in create values matches the one in the context.
Note: it was already the case but kinda by chance and not entirely
correct. Most of the time, the 'arch' field was specified as a creation
value... and as it is a computed field with an inverse method, a COW
was triggered. But this had also the inconvenient of creating an extra
generic view without any arch.
closesodoo/odoo#43245
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If an email was sent with empty "To:" and a proper alias in "CC:" (or any of the similar valid headers that conform the `rpc_tos_localparts` array), before 40ae36b7f8c412cd96dc9592d8d1fb90de1e52d2 the email wouldn't get rejected. After that commit it would get bounced.
This comes from the not-so-obvious new python idiom used, `all()`. Check this out:
```python
>>> all([False])
False
>>> all([])
True
```
So, apart from the fix introduced in that commit, which seems valid, we have to make sure `email_to_localparts` actually has contents. Otherwise we are producing false bounces here.
@Tecnativa TT23437
closesodoo/odoo#64528
X-original-commit: 8f094d3c01a6ad150b7945115cda515dbde1f4bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the name of a partner contains a regular expression operator, such
as grouping parenthesis, +, *, brackets... the resulting regexp may
match wrong names or worse be invalid and lead to an exception.
With this commit, we create a regular expression from only the words
formed from at least 3 of [a-zA-Z0-9], ignoring all other characters,
including those who may have a meaning in a regular expression.
This avoids these issues:
- regexp injection (security issue)
- punctuation resulting in erroneous regular expression ("ABC + SPRL"
resulted in "(?=.*ABC.*)(?=.*+.*)(?=.*SPRL.*)" which is invalid at
the ".*+" part)
- false positives due to words that are too small (\b were added, and
the minimal matching word size is 3)
- accentuation mismatch (both sides are filtered through unaccent)
- special cases in unicode that have a special behavior with lower().
See the discussion on odoo/odoo#63145 for a detailled explaination about
these issues.
OPW-2360687
closesodoo/odoo#64510
X-original-commit: 3c5296863f0030acc5d3dba0ff73a6f1b42d1255
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
In order to easily compare delivery slip from vendor and receipt, vendor
product name and reference should be visible on the receipt operations.
The receipt description was just the name of the product before, it is
now taking the same description as the PO line, using vendor product
name and reference if it exists.
Task ID-2411544
closesodoo/odoo#62967
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If a user has no access to Invoicing module, he can not send and print his invoices.
To reproduce the error:
(Need sale_management,account)
1. Connect with admin account
2. Settings > Users & Companies
3. Create/Edit a salesman
- Remove access rights to Invoicing module
4. Connect with this user
5. Create & Confirm a SO
6. Edit the SO and fill in the "Delivered" field, Save
7. Click on "Create Invoice", "Create Invoice"
7. Connect with admin account
8. Invoicing > Go to the previously created invoice
9. Confirm it
10. Connect with the user account
11. Sales > previously created SO > "1 Invoices"
=> The user can read the invoice, but he can not send and print it. This is an error.
OPW-2389428
closesodoo/odoo#64508
X-original-commit: f64f7ca309f9228e58b1487a286f2302ff8f035e
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Reconciliation models can now create partial payment on invoices. Because of that, the default behavior is not anymore to fully pay the invoice and create an open balance write off.
In some cases, though, this is what we want (exchange difference, ...). The solution for that is to create a reconciliation model with write off lines (telling it it must only apply if there is a 90% percent match on the amount, for example), and then create another one not checking the amount to just match the things to reconcile partially by using the partner.
However, as it is now, reconciliation models always bypass the check made on the amount in case the statement line's label matches the invoice's payment reference exactly. This can lead to cases where we are matching elements we shouldn't with the rule doing the write off.
Example:
- use only two 'invoice matching' reconciliation models, in the following application sequence:
- model 1, matching partner if with amount matching percentage is 90%, and doing a write-off for the unmatched amount
- model 2, matching partner with no amount matching percentage, and no write off
- create an invoice with payment refrence INV1 for partner A, amount: 100
- create an invoice with payment refernce INV2 for partner A, amount: 200
- create a statement with two lines:
- line 1, with 99 for partner A, label= INV1.
- line 2, with 1 for partner A, label= INV2.
- Open the reconciliation widget
==> Before the fix:
model 1 is applied on both statement lines, as their label match payment references. This is what we want for line 1, but probably not for line 2, which will create a write off of 199, while we'd have wished for a partial payment, leaving the invoice with 199 open.
==> After the fix
The behavior is the same unless the config_parameter is set. If it is:
- line 1 will be matched by model 1 (as 99 - 9,9 < 100 < 99 + 9,9). INV1 will be paid with a write off of 1.
- line 2 will not be matched by model 1 (as 200 is not between 1 - 0,1 and 1 + 0,1), but it will be by model 2 (since line 2 and INV 2 share the same partner). So, INV2 will be partially reconciled with line 2.
OPW 2419030
closesodoo/odoo#64504
X-original-commit: ed023e208736e58d14649aa2fd91fb00510f20c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The issue was triggered by the fact that editable fields are no longer
computed when they have a default value.
closesodoo/odoo#64503
X-original-commit: f047e0bdbcea2b707ecd24c6badbc3bfff0a71e9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This partially reverts commit 1ec887b773,
which was a hack to deal with the issue. From now on, the first call to
onchange() no longer computes editable fields when they are given a
default value.
X-original-commit: c01657d345f59e3ccea70a5004732050fae99320
Consider a model with a field F and a computed editable field G that
depends on F. Assume we open a form view, and both F and G have a
default value. The first onchange should return F and G with their
respective default values. In other words, the field G should not be
recomputed even if its dependency F was assigned a default value.
The use-case that showed the issue is batch payments. When adding a new
payment in the one2many field of a batch, the new payment should use the
batch's payment method by default. The default value for the payment's
method is assigned by context on the one2many field in the view. Before
this patch, the new payment's method was given by the computation of the
field, and its default value was ignored.
Side note: another test was fixed, but that's because the test was not
consistent with the way Odoo 14.0 manages defaults and onchanges.
X-original-commit: 2ccc735253405b03927e2b08eab57427e65e4050
Purpose of this commit is to move moderation tests directly into mail channel
test file. That way it is easier to maintain or update them as they are
linked to that specific model and not global to mail.thread.
Also containing
* remove unnecessary tests or merge tests belonging to the same category;
* make tests more readable;
Followup of odoo/odoo@e9571a4
Followup of odoo/odoo@1fadb3ec5d
Task ID-2421795
closesodoo/odoo#64501
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 'move_line_ids' isn't inside the view, `account_type` is never computed and then, the accrual account is never displayed/editable on the view.
closesodoo/odoo#64495
X-original-commit: cefbd5f3adebe1c620c070f7767d368e65242d37
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Summernote uses execCommand and, worth, obsolete queryCommandState
function to customize the edited content. Here we try to hack the
function to solve some problems by making the DOM and style easier to
understand for the base functions for the duration of their executions.
This won't obviously solves all problems but this is an improvement
while waiting for the new Odoo editor coming in future versions.
The original problem this solves is handling bold text in blog posts.
Posts are using font-weight: 300 which is enough to confuse summernote.
Hitting bold on a selected paragraph wraps its content in a <b> tag but
hitting bold again does nothing... having a <b> rendered as fw-400 is
enough to break it. What this commit does is: before any execCommand or
queryCommandState being used to modify the DOM or retrieve its state,
the whole DOM is forced to fw-400 and <b> elements to fw-700. This also
solves issues in some base snippets.
closesodoo/odoo#64483
X-original-commit: 424d9661c5657cbcf10ce40acb94a7a200c2a48b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps:
- Install website_sale and payment_authorize
- Set up a tunnel (e.g. ngrok)
- Log in to Authorize.Net backend
- Go to Account > Response/Receipt URLs > Add Url
- Enter the tunnel URL
- In Odoo, go to Website > Configuration > eCommerce > Payment Acquirers
- Edit "Authorize.Net"
- Credentials tab:
- State: Test Mode
- API Login Id, Transaction and Signature key
- Save, then Generate Client Key
- Configuration tab:
- Payment Flow: Payment from Odoo
- Stop the server
- Replace https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/payment_authorize/models/authorize_request.py#L46 with `resp = {'messages': {'resultCode': 'Error', 'message': [{'code': 'E00027', 'text': 'An error occurred during processing. Call Merchant Service Provider.'}]}}`
- Restart the server
- Go to "Website" > "Go to Website" > Shop
- Add a product to the basket
- Check out the basket
- Choose "Credit Card (powered by Authorize) Test Mode"
- Pay Now
- Enter any card data (e.g. 4111 1111 1111 1111 - 01/22 - 900)
Bug:
When the Pay Now process is done, the customer is redirected to
`/shop?error=invalid_token_id`. No errors are shown.
Explanation:
The patch simulates an error from Authorize.Net happening during their
process. Using the special card numbers won't trigger the wanted
behavior.
When getting an error from Authorize.net, a `UserError` is raised. This
error is then caught in the controller to return a formatted message.
However, returning a dict in this part of the code embeds it inside
`{'result': [...]}`. The error message is, thus, not blocking the form's
redirection and the user gets redirected to the form action, i.e.
`/shop/payment/token`. This route requires `pm_id`, but, in this
scenario, it's an empty string. This leads to another redirection to
`/shop/?error=invalid_token_id` as seen here:
https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/website_sale/controllers/main.py#L938-L941
Letting the error bubble up forces the backend to return a blocking
error response. This makes the fronted display the Authorize.Net error
underneath the provider selection, and prevents it from redirecting.
opw:2419260
closesodoo/odoo#64482
X-original-commit: 2636b9f5059808b443be67b06fca129cf9d3a913
Signed-off-by: backspac <backspac@users.noreply.github.com>
The picking_type and currency were taken from the current company, even if the
purchase order is created in another company.
Fixes#35026closesodoo/odoo#64481
X-original-commit: 75936208c6e76a012027952f43b598e9d20180f3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit fixes a small design glitch in the user form by replacing a "X"
character to close an alert by an actual close icon.
Which looks better, the "X" really sticks out from the rest of the design.
Task n°2393814
closesodoo/odoo#62368
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Belgium, the company registry and the VAT number (no country code) are identic.
The company registry field is not mandatory, but is needed to export the belgian Intrastat XML file.
Now:
- belgian company registry is set by default to vat number.
- missing company registry warning message redirects to company settings.
closesodoo/odoo#58047
Task: 2335088
Related: odoo/enterprise#15270
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
PURPOSE
Provide various fixes related to mass mailing (sms) and marketing automation
applications.
SPECIFICATIONS
See sub commits for more details.
[FIX] link_tracker: disable create and edit on clicks list view
[FIX] sale: prevent creating quotations from UTM campaign reporting buttons
[REF] mass_mailing: split mailing.trace.report sql to ease inheritance
[FIX] mass_mailing: let subscription_ids won over default_list_ids
[FIX] utm: fix naming of utm campaign card
[FIX] utm: show campaign tags by default by giving them a color
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031closesodoo/odoo#63271
Forward-port-of: odoo/odoo#59872
Related: odoo/enterprise#15278
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Colorless tags are not displayed in kanban view of utm campaigns. When creating
tags on the fly currently they have no color and are therefore not displayed
once saving the campaign. This is not really intuitive for users.
We now set a default value to color field of tags. They are now displayed
by defauklt.
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031
X-original-commit: 4f83be33d4cc53d50081050b3a9dee2892c562a4
When creating new contact coming from a mailing list a default_list_ids
context key is set. It is used to give a default value to list belonging
and also to compute opt_out.
However subscription_ids field is displayed on contact form view, allowing
to add the contact to mailing lists. We may end up in situation where a list
is given twice to a contact: once through default_list_ids and once through
subscription_ids field manually completed by users.
In this commit we therefore merge those two values when creating contacts.
Also improve some wording while we are at it.
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031
X-original-commit: 30bab79183b4b9f1a571d6ebd9bbc1f3c0692457
Purpose is to ease inheritance of generated SQL report for mailing traces.
Notably we want to be able to filter out some mailings like those used
in marketing automation.
For that purpose we rework the hardcoded string to be a bit easier to
inherit. It is now build based on various sub methods returning sql items
(columns, group-by, ...) that are then aggregated to make the final SQL
query.
Functionally nothing changes. String manipulation is feasible as there is
no user input, meaning only valid terms will be accepted in final SQL.
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031
X-original-commit: 15783a7dcfacc5904b3d3c823f175a4be5667129
Configure the incomming mail server, use another mail client to send a
message to Odoo with an EML file as attachment. The fetchmail server
fails.
Since the introduction of the new EmailMessage python API to
encode/decode email messages, every EML attachment is automatically
parsed into a EmailMessage.
closesodoo/odoo#63255
Task: 2329606
X-original-commit: e628defec14f3b36612951bc698fa51b7c9f56bb
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
- Install stock
- Create a Storable Product
- Add an Attribute with Variant Creation Mode set to Instantly (i.e. Color)
- On Product form, click on Variant smart button and open a Product Variant
- Click on "Update Quantity"
The Create button to edit Quantity on Hand is not present.
This comes from the Variant smart button (id: product_variant_action) that adds
'create': False in the context to prevent creation of Variant.
But when navigating to Update Quantity page, it is still in the context and hides
the Create button.
opw-2412380
closesodoo/odoo#63272
X-original-commit: 3d671ef824fec9dc8ee7d3666b6e528a3c794226
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Make the element #wrapwrap be placed directly in the body as in 14.0
instead of wrapped inside containers.
FIX: [QSM] Header effects don't work in edit mode even though they are started
FIX: [QSM] The editor overlay on top of snippets does not disappear during scroll
anymore
FIX: [QSM] Click on the header, it is deletable while it should not (I precise
that here asit is a kinda different case: the header has options even though
it's not editable but it's not deletable)
closesodoo/odoo#63268
X-original-commit: e0331583cf995b7cfe7d7928918c71b51c854f2d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1) Replace editor function that change the editor internal structure
with a new mechansim that does it automatically by observing dom
mutations. Welcome wysiwyg.withDomMutations.
2) Add a mechanism to reuse the active editor execution context
when a wysiwyg.execCommand or wysiwyg.withDomMutations is called
inside itself.
Example:
await wysiwyg.execCommand(async ()=> {
...
await wysiwyg.execCommand(()=>{...})
await wysiwyg.withDomMutations(()=>{...})
})
closesodoo/odoo#63237
X-original-commit: fe7056ccb450c9767693671e8d980a6aebacd6ab
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Changelog:
[IMP] Odoo: allow empty structure nodes
[IMP] Odoo: expand parsing range of OdooStructureNode
[FIX] DomHelpers: removeNodes only when they exist
[FIX] withDomMutations : getParentModifiers
[FIX] withDomMutations: don't get node loosely
[FIX] withDomMutations: remove the proper observer
[FIX] OdooField: do not apply empty class if placeholder
[FIX] OdooWebsiteEditor: add expected Theme plugin
X-original-commit: 537c3318a6f2751d83a011345602456125420590
Right now, the quick create kanban card is having three buttons, Add, Edit
and Discard. In some languages, the translation terms of these buttons may be
quite long. This pushes the last button into second line and leads to an
ugly display.
This commit replaces the 'Discard' button with trash icon and makes sure that
all buttons are always in single line. If the strings are too long, they will
be cropped automatically.
Task ID-2373130
closesodoo/odoo#62326
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When installing/upgrading a module with broken xml views, the module
installation fails with an error message that should help the developer
locate and correct the error.
Before this commit, a 3-level traceback was thrown at the developer:
1. The initial ValueError containing the original error message and some
view context information.
2. The noisy re-cast of the ValueError to a ValidationError with no
additionnal information.
3. An additionnal re-cast of the exception to add the original source
file path plus the entire XML source code that failed to be parsed.
We argue the error contains too much noise as developers are mostly
interrested in correcting their erronous tag of their view, they are not
interrested in `ir_ui_view` internals.
The new exception report is much less talkative, the two tracebacks from
`ir_ui_view` are logged at the `DEBUG` level. The new exception still
contains the original error message with some context on the view record
and the original source file path but it only show 5 lines of XML around
the erronous tag.
closesodoo/odoo#62757
Task: 2366612
Related: odoo/enterprise#15104
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Create a model as follow:
class FooModel(models.Model):
_name = 'foo'
bar = fields.Char(compute="compute_bar")
@depends('bazz') # wrong dependency, bazz does not exist
def compute_bar(self):
for rec in self:
rec.bar = "Babar raconte des beaux bobards."
Uppon -u foo_module, a ValueError is rose for the invalid dependency
with the following message:
> Field foo.bar cannot find dependency bazz on model foo.
We had feedback the error message was not very clear to some users,
the new error message is:
> Wrong @depends on 'compute_bar' (compute method of field foo.bar).
> Dependency field 'bazz' not found in model foo.
closesodoo/odoo#62328
Task: 2366612
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Introduce a way to schedule the execution of cron jobs *soon*. Triggered
jobs are included in the next execution batch.
Heavy refactor of the `ir.cron` model so the various parallel queries
use the (not so new) `SKIP LOCKED` postgresql select option which skip
rows that are locked instead of throwing an exception like `NOWAIT`
would do. Various methods has been renamed and the overall selection,
execution and update of job records have been re-architectured.
The cron workers can now to wake up early via a notification on the
`cron_trigger` channel of the meta `postgres` database.
closesodoo/odoo#62124
Task: 2368911
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
After an activity creation, if a user checks the activity's information,
the creation date will be the current date.
To reproduce the error:
1. Add an activity (e.g. a TODO activity)
2. In log notes, click on the activity's information icon
=> The "Created" field is actually the current date and not the
activity's creation date.
OPW-2412967
closesodoo/odoo#63233
X-original-commit: f25da5fef15d10b184d744bf5533b90364a35a81
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Thread search with `message_has_error` should only return threads containing
messages with failure of which the current user is author.
Follow up on https://github.com/odoo/odoo/pull/52403 that changed how
sub-queries were built. The current fix using `_search` is a non-ideal solution
until task-2366651 brings a new domain operator for this use case.
task-2409543
closesodoo/odoo#63231
X-original-commit: 337397eec5570fc9b3938d655a1ec0e4efcd73d9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Pierre Paridans