Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
When enable, this new feature adds the possibility to set a PDF header, footer and some product
documents to the quotation report.
These PDF can contains forms that'll then be filled using Odoo database.
This replace the previous sale quotation builder feature.
task-3249142
closesodoo/odoo#133773
Related: odoo/upgrade#5168
Related: odoo/documentation#5863
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Since https://github.com/odoo/odoo/pull/110737, it is better to use
`_read_group` instead of `read_group` in the backend. In fact, the
public method is less efficient (it computes display_name of relational
groupby, extra order, ...) and more verbose.
This commit replaces these new uses of `read_group` with `_read_group`.
closesodoo/odoo#136381
Related: odoo/enterprise#47826
Signed-off-by: Raphael Collet <rco@odoo.com>
The model `account.analytic.line` has a field `so_line`.
In module `sale`, this field has a domain, which is defined in
`_default_sale_line_domain()`.
In module `sale_timesheet`, we override the method to add another
condition to super's.
The issue is that we also add the arg `dommain=...`, in the field
definition, which totally overrides both methods.
Moreover, it is impossible to just move that domain in the method,
because it has to depend on `self.commercial_partner_id`,
but the method is static.
The solution is to:
- Keep `_default_sale_line_domain()` in both modules,
but not call it directly from the field.
- Create a new compute field (`allowed_so_line_ids`),
to determine all allowed so_lines,
following the domain that is returned by those methods.
The compute method will call the domain method on instances, which
allows us to get their `commercial_partner_id`
- Replace the domain arg of `so_line` by `[('id', 'in', allowed_so_line_ids)]`.
task-3507195
closesodoo/odoo#135528
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit changes the way transactions linked to a document (sales
order, invoice...) are created in a payment flow. Rather than receiving
and trusting the transaction values from the controller, they are now
read from the linked document, and the payment flow is rerouted to use
the document's module's controllers instead of that of `payment`.
This ensures that no unexpected value can be passed to the `create`
method of a transaction, and simplifies the implementation of the
payment flows of linked documents.
task-3136240
closesodoo/odoo#126425
Related: odoo/enterprise#43212
Related: odoo/upgrade#5124
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This previous commit : https://github.com/odoo/odoo/commit/d197efa60cf7c00168847ce7afcfa1741410aee1 aimed at ventilating rounding error corrections on multiple lines. But this would introduce errors or unbalanced moves if the rounding amount/lines quantity was smaller than the rounding of the currency. E.g. à 0.01€ error divided on 3 lines would add 0.00333 on each line, and when the amount is rounded, it would vanish.
closesodoo/odoo#136366
X-original-commit: 0627b4609e8b1b3d15651d6cde0ff4cfdc85c5d6
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a user creates a downpayent with a fixed amount, the amount is tax included. This can generate rounding issues as sometimes the amount is impossible to be reached by any base amount / tax combination. (fixed amount = 100€, tax is 21% -> 100/1.21 = 82.64 -> 82.64 * 1.21 = 99.99). This can lead to up to 1 rounding error per downpaylent line.
Until now the total amount delta was added/removed on one tax line, one receivable line and one product line. While the total amount was correctly corrected, the amount on the individual lines would be off.
On a SO with :
base | tax | tax incl
1000€ | tax_21%_a | 1210€
1000€ | tax_21%_b | 1210€
Generate 1 DP for fixed amount 200€
Invoice lines :
BEFORE:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.01 <-- 0.02 correction
tax_21%_b | -82.64 | 99.99
tax lines -----------------------
| -17.37 | 0.0 <-- 0.02 correction
| -17.35 | 0.0
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
AFTER:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.0 <-- 0.01 correction
tax_21%_b | -82.64 | 100.0 <-- 0.01 correction
tax lines -----------------------
| -17.36 | 0.0 <-- 0.01 correction
| -17.36 | 0.0 <-- 0.01 correction
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
closesodoo/odoo#135698
X-original-commit: d197efa60cf7c00168847ce7afcfa1741410aee1
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Downpayment might have been determined by a fixed amount set by the user.
This amount is tax included. This can lead to rounding issues.
E.g. a user wants a 100€ DP on a product with 21% tax.
100 / 1.21 = 82.64, 82.64 * 1,21 = 99.99
This is already corrected by adding/removing the missing cents on the DP invoice
but it would still be wrong when creating the final invoice (as it is based on the actual base amount + tax of the SO DP's)
opw-3466409
X-original-commit: 0a6e2d47107727040664176740535707286a1355
Part-of: odoo/odoo#135698
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
This commit mainly removes the extra indent level left over after commit
odoo/odoo@8ec2e8cf. It also cleans up purely cosmetic code styling
inconsistencies.
task-2882677
Part-of: odoo/odoo#120446
Steps to reproduce
==================
- Use a mobile viewport
- Create a quotation
- Add an order line
- Set a packaging
-> The Packaging Quantity field is missing
The same happens on purchase orders
---
opw-3504829
closesodoo/odoo#136213
X-original-commit: c5d665cc2b43a0040c3f5644265e74048c3d5ded
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, each module had its own logic regarding payment
flows in the portal. With this commit, we enforce that if the user is
logged in, they see their tokens, while logged out users see the tokens
of the customer (the contextual partner).
task-2836870
closesodoo/odoo#124631
Related: odoo/enterprise#42999
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some businesses requires customers to pay a down payment in order
to confirm the order. In the case of odoo today this implies to:
- sending a payment link
- waiting & checking if the payment has been done
- confirming the order
- creating the down payment invoice
A lot of time consuming manual operations with a high risk of errors.
This commit introduces the functionality for sales orders to be
confirmed on down payments and automatizes the flow to minimize the
errors due to human manipulation.
Task - 3087716
Part-of: odoo/odoo#124297
Co-authored-by: Victor Feyens <vfe@odoo.com>
Purpose
=======
The customer reference is a string that can be added to a SO
(in Other info page). It is well visible when downloading or printing
a SO but not in the overview in the Portal.
Specification
=============
Add the Customer Reference in Sales Order and Quotations if it has been filled.
Task-3355199
closesodoo/odoo#124217
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- cost= $100
- Create a repair order:
- select any product in the product to repair
- add “P1” as component
- create the quotation from the repair order
Problem:
The cost is not computed correctly and is set at 0 in the
`sale.order.line`
opw-3502317
closesodoo/odoo#135822
X-original-commit: b95ed3617f465a655c8f918bee8edc673c8f202b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Clean all code related to _get_combination_info:
* Move logic to website_sale now that backend configurator doesn't
rely on it anymore. Only frontend configurator uses that logic.
* Make sure the returned information is correct and consistent:
* request must be given the right context (multi-company)
* behavior is coherent between modules and overrides (date, company, currency, rounding)
* Performance:
* Avoid loading unnecessary information
* Avoid calling _get_combination_info when only part of the data is necessary.
* Clean/simplify uses and overrides by keeping useful information in the combination_info dict (taxes, currency, ...)
* Code cleanup
* clean imports
* clean architecture
* clean templates
* move old configurator code to website_sale
Now that the product configurator backend side has been redone
completely, the remaining parts previously shared between backend
and frontend configurators can be moved to website_sale because only
used by the frontend configurator.
Part-of: odoo/odoo#121986
Activate analytic accounting
Configure a [TEST] product to create a project on order
Create a SO with [TEST]
Have an expense product [EXP] with reinvoice policy set
Create an expense with [EXP] and set as analytic account the one created
for the SO and another one
Complete the expense flow
Check the SO
Issue: the expense line was added correctly but the quantity delivered
is set to 2
opw-3410712
closesodoo/odoo#135479
X-original-commit: 39f573eebd7af7f026ffdcb4957a47a0f699939f
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Establish a set of target font-weight values (may not directly match the
final result on screen).
Enable the system to naturally utilize the "bolder" font-weight.
Remove previous customizations designed for "Roboto" that clashed
with certain system-fonts.
Enforce the "normal" font-weight for icons, regardless by their parent
design.
Adapts some kanban titles.
closesodoo/odoo#134824
X-original-commit: 74fce06cad4000a3894757d4fef9074b64153b7b
Related: odoo/enterprise#47140
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
When rendering the sale order cancellation message,
the rendering should apply the current user record rules,
for instance the count of the partner sale orders should
match the count of what the salesman can see in his ui.
Otherwise he doesn't understand why he has a different count
in the UI and in the cancellation message.
In case you want the behavior of seeing all records
and not just the current salesman records only,
then you apply within the template itself the
`sudo()`.
Applying the `sudo` where you actually need it in the template,
and not computing the full subject/body as sudo,
offers more granularity.
closesodoo/odoo#135233
X-original-commit: 5d49a08f60b1f299784e2e983e87cdec178642c1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Improve the color of quantity selector and add button.
- Currently, if we look at the selected quantity, it is not that visible on the
projector.
- The color of the quantity selector and button change to primary and secondary
respectively.
closesodoo/odoo#134244
Task: 3489423
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
From an internal feedback, someone reported that the code added:
e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
might cause an issue in case of several sale order linked to the same
invoice line.
With this changeset, in this case we will have the same behavior as
before, eg:
- one sale order line (SOL1) has amount_total 700
- one sale order line (SOL2) has amount_total 1400
if the invoice line linked to both line has price_total:
* 700 => amount_to_invoice of: SOL1 will be 0, SOL2 will be 700
* 1400 => amount_to_invoice of: SOL1 will be -700, SOL2 will be 0
* 2100 => amount_to_invoice of: SOL1 will be -1400, SOL2 will be -700
opw-3437237
closesodoo/odoo#133498
X-original-commit: 15a90c9f6cbf5a1750fafee994fda4b6ec2ebc14
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently there is no efficient way to suggest extra-options to
customers in PoS or eCommerce. Extra options should be easily selected
by customers (or PoS waiters) with checkbox. Each checked option would
add an extra-price to the product price and appear on tickets,
receipts, invoices, kitchen display, ...
This commit introduces a new type of attribute: multi-checkbox. This
will not create product variants. A default extra-cost is defined at the
attribute level, but it can be changed at the product level.
The new attribute is available in Sales, not yet in eCommerce nor in PoS
(it will be in a future task).
task-3256585
closesodoo/odoo#130915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since https://github.com/odoo/odoo/pull/122085, on the sale
order form (with website_sale installed), changing the "Customer"
changes the "Invoice Address" & "Delivery Address". But the latter
are displayed with the partner name, but also with the full
partner address. This last information makes the form uglier than
before and are useless.
The old `display_name` of `res.partner` was stored in the DB and
did not depend on the context. Also, onchange calls add the
context of the source field (the one being changed). In this case,
`'show_address': 1` is added, and then `display_name` of
`partner_invoice_id`/`partner_shipping_id` is also read with this
context.
We cannot easily fix this in saas16-4 because it was not possible
to change the read context of a particular field. With the new
specification of onchange, we can override the read context on a
particular field.
closesodoo/odoo#134304
Signed-off-by: Raphael Collet <rco@odoo.com>
The goal of this task is to help user manage their sale_order
by having a summary view of all their next activities.
Sale calendar view is now based on the next activity for each
sale_order.
closesodoo/odoo#132287
Task-id: 3463325
Related: odoo/enterprise#45945
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This traceback arises when a user tries to make a payment on the website.
To reproduce this issue:
1) Install 'website_sale'
2) open invoicing/configuration/journals
3) Change the journal type if it is 'sales'
4) Install and enable 'Wire Transfer' payment provider in
invocing/configuration/Payment Providers
5) Now open 'website/shop' add any product to cart and proceed to checkout
6) Make a payment with 'Wire Transfer'
Error: 'ValueError Expected singleton: account.journal()'
On '_compute_sale_order_reference' method, 'invoice_journal' variable
is getting values with the reference of 'type=sale'.
See:-
https://github.com/odoo/odoo/blob/ebc4ed6c4fb11b01be28cf417b27de83d5361cef/addons/sale/models/payment_transaction.py#L20-L30
Because of user changed the type of journal, 'invoice_journal'
value will be empty recordset and it is referenced to call
'_process_reference_for_sale_order' method.
In '_process_reference_for_sale_order' method ensure_one() is used,
which leads to above traceback.
sentry-4392496618
closesodoo/odoo#134083
X-original-commit: c880a295d0f7feff48b08fd00723a41b8d564d2d
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
before this commit, on inheriting the function
_get_custom_rendering_context_values the argument values are not received
in the inherited function as it is not passed along with the super
scenario:
* consider that the payment link is shared to customer
* customer made the full payment
* once the sale or invoice is fully paid, the link has to
be shown as fully paid or expired
* for doing this, if we inherit the above function, the
arguments is not passed to the function
after this commit, the argument values are passed to
super and the value can be used re used in the further
inherit of this function
closesodoo/odoo#134195
X-original-commit: 49b91e47c6c24e0023110365e7f9084a2c13ca5a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
The purpose of this commit is to add the alwaysApply option to useDebounced.
This option is used to force execution of the callBack if the debounced
function has been called and is still not resolved when the component is destroyed.
closesodoo/odoo#134096
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in the kanban catalog view, when you make a groupBy
or update a record (click on the star), a crash is displayed.
Why does this happen?
The RPC for "sale_order_lines_info" is called during loadData of all dataPoint types.
Solution:
The RPC for "sale_order_lines_info" should only be called for DynamicRecordList.
closesodoo/odoo#133907
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Create [TAX] as 21% included in price tax
Create a Sale Order with the lines:
- Product A, qty 1, unit price 900$, tax [TAX]
- Product B, qty 2, unit price 90$, tax [TAX]
- Product C, qty 4, unit price 49$, tax [TAX]
Confirm order
Create a downpayment with fixed amount of 550$
Go to the downpayment invoice
Issue 1: price total on the downpayment line is 549.99
when we make the downpayment we convert the fixed amount in percentage
and then compute the downpayment amounts.
This result in some rounding issues that are only partially corrected
The price total on the product line was not corrected
Confirm the downpayment invoice
Go back to SO
Hit create invoice again
Issue 2: 'Already invoiced' amount will be 549.99
When the make invoice wizard is created we operate on virtual records of
SO and invoices.
In particular, when the amount_to_invoice is recomputed, instead of using
the value saved in DB the system recompute the total of the downpayment
invoice from the lines, introducing a rounding error which is
manually corrected only when creating the downpayment
opw-3466409
closesodoo/odoo#133836
X-original-commit: e1c85283736deac7dd523f115e6ba9033b656ade
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- only attributes related to products currently visible are
visible,
- duplication of attributes names in the search panel is solved.
task-3367295
closesodoo/odoo#126796
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Preparing the sales catalog to odoo 17 release:
- visual tweaks:
- color of the selected product more appealing,
- removing visual noise (border line),
- adapting dark mode,
- removing add adding spacing and margin where is needed,
Task - 3367295
Part-of: odoo/odoo#126796
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- fix the concurrency bug of removing items with the "Remove"
button not happening sometimes
task-3367295
Part-of: odoo/odoo#126796
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- adding a button "Back to Quotation" to ease the navigation,
- make the "empty" help message more friendly and add a button to
directly create a product,
task-3367295
Part-of: odoo/odoo#126796
In 89d5d1f, changes have been made to the catalog to ease inheritance.
Since this change, opening the catalog with products spread over
multiple lines on the SO crashes.
Now, the catalog will open even if the SO contains products spread
across multiple lines.
closesodoo/odoo#133217
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Jorge Pinna Puissant