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>
Issue
- Create a Price list and set 'Discount Policy' as
"Show public price & discount to the customer "
- Create an SO
- Add a multiple product with at least one with price unit = 0
- Change the pricelist and update prices
Cause
Division by zero when calculating discount.
Solution
Calculate discount only if there is a price_unit.
opw-2393790
closesodoo/odoo#63218
X-original-commit: 9f70f405bc453ce56b75d22a318c9fd72e8bd496
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before, when only invoicing is installed (e.g. in case of the PoS), a
not so easy to surpass error would be triggered when using products
with a lower tax rate, e.g. drinks are only at 7% instead of 19%.
Because there is a constraint, upon validation of the invoice, that the
accounts used must correspond with the tax rate and you can not set a
specific account in case of only invoicing, an error will be raised when
you try to validate the generated invoice.
We solve it by inheriting the method searching for the product accounts and
when no income/expense account on the product is set, but a tax is, to suggest
the account corresponding to the tax and its rate if it would suggest a wrong
account.
closesodoo/odoo#63201
X-original-commit: 6b6387e88232928e67cb36b74371be72a3b4c441
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
If a RFQ/PO is created with a specific company, its number must
be assigning using the sequence defined for that company with
disregard to current environment company. E.g. This issue can
easily arise when using aliases to create RFQ's.
closesodoo/odoo#63175
X-original-commit: 5de36feffd0347ff28c8fa35818e7bfc2535df4e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
You may want to use an analytic account for several projects of different companies, thus the correct way to proceed should be removing the company of the analytic account.
closesodoo/odoo#63172
X-original-commit: f1005e7624e84e6ee7ef467ae3bbccd16c59ce99
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When trying to get the im_status of several partners, if one of them
does not exist, it will return an error.
To reproduce the error:
1. Go to Contacts
2. Open a contact
3. Action > Delete
4. Wait max 50 seconds
=> A Missing Record message is displayed. The im_status RPC includes the
deleted partner's identifier and the server looks for it.
Now, the server skips the missing identifiers.
OPW-2390719
closesodoo/odoo#63198
X-original-commit: a35c65032fc5ed1371957c362921bf5fa30062ff
Signed-off-by: adwid <adwid@users.noreply.github.com>
Before this commit, the background-position was not removed from a
shape when it was re-flipped to its original orientation.
introduced in #61114closesodoo/odoo#63197
X-original-commit: 597585c9b8b1350bcfd84e8433ea6c82060bcc3d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Thanks to Layline Tech for the update and cleaning out
closesodoo/odoo#63193
X-original-commit: 943e7d0f0af836c390dc3bf0c1634aacf32f2286
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Currently when creating a calendar.event with google sync switched
on and without adding another attendee, the event is immediatly
removed from the calendar view. This is because the user_id is filtered out
of the attendee_ids before sending the values to google calendar. Then, at
the next sync, google response attendees list does not contain the user_id
so Odoo turns that into a [(3, id)] command. Thus, the corresponding event
disappear from the current calendar view even though it is still in the DB.
This fix is essentially the same as the one implemented in the
microsoft_calendar addons available from 14.0 onwards. It adds the
calendar owner if the event organizer is not null. This way, even
though the owner is not sent as an attendee, it is not removed
after google's response.
closesodoo/odoo#63190
X-original-commit: 04aa586a53c2b78cf6646d96d29cbd1e8969de3f
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, attempting to delete attachments multiple times
could result in errors, especially on slow networks.
This commit fixes this issue.
task-2363522
closesodoo/odoo#63189
X-original-commit: 528adfb313ab3c8d4aeb3309aa7371301ab8085e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Adrien Widart