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>
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>
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>
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>
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 "fees" or "extra fees" or "customer fees" feature was meant to make
customers pay for the processing fee charged by the payment provider
they choose to make their payment. The fee was also displayed on the
payment form to deter customers and encourage them to choose another,
cheaper, payment provider.
In practice, it didn't hold up because:
1. the provider's API must allow sending the fee as a separate amount,
and PayPal was the only supported provider to do it;
2. charging extra fees is highly discouraged by providers, and forbidden
in Europe;
3. the final fee amount depends on the customer, country, payment
method, risk profile... rendering charging the actual fees amount
infeasible;
4. most of the time, only one payment provider is enabled at a time,
thus alienating customers who would have no other choice than paying
the fee;
task-3358581
closesodoo/odoo#132104
Related: odoo/documentation#5517
Related: odoo/upgrade#5053
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Previously, customers were not allowed to sign a draft quotation.
We consider that if the customer has access to the quote, he should be able to sign/pay it (instead of getting some strange feedback that the order is not in a state requiring signature/payment)
task-3340541
closesodoo/odoo#124486
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
Before this revision, when you pass `context` in the arguments
of a JSON routes, this one gets automatically injected
in the environment context.
This is not the case for regular HTTP routes.
It makes sense to propagate the context for the JSONRPC protocol,
JSON routes used by the backend, such as `call_kw`,
but it doesn't make sense to pass this context automatically
for any other kind of routes, such as front-end routes
or routes used by custom Javascript widgets.
This change brings a more unified behavior for routes
of types HTTP and JSON.
In addition, most developers were not aware of this "feautre",
that passing `context` in the arguments of a JSON route leaded
to the injection of this context in the environment context.
This is actually reflected by the diff size this changes required,
only a dozens of routes needed to be adapted, to manually
add the context in their route arguments and to inject it
in their environment context.
closesodoo/odoo#121726
X-original-commit: a7a5655631e6d5b05fd2ba3d0c80617aae6d9cfe
Related: odoo/enterprise#41229
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The note "Quotation viewed by customer" posted when a public/portal user
access an order came with the order's partner name instead of the actual
user's partner name
This made confused for internal users to see something in internal note
like **Colleen Diaz** with a message **Quotation viewed by customer
Nicole Ford**
This commit makes sure to use the right partner name except the
quotation is viewed anonymously (with access token)
closesodoo/odoo#121571
X-original-commit: 8e37dcee1f5106e69d5784439e2657acf5706e4e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, Fields Sales are struggling to create quotations or sale
orders directly from the customer place. One of the issues is that it
is not easy to quickly add products to the SO. Products must be added
one by one and, in mobile, it requires completing a form with
quantities, ... for each new line.
This commit introduces a catalog view that allows users to select
products in a faster and easier way than before, both in desktop and
mobile view.
Task - 3062080
closesodoo/odoo#106382
Related: odoo/enterprise#37915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: chevalierv <vcr@odoo.com>
When using a different invoicing address for a partner on a sale order,
an error is thrown up. This is caused by checking the wrong partner in
the access token.
opw-3298228
closesodoo/odoo#120822
X-original-commit: bd76e9d6174d2154f8685dbaa2c8dcf1678ac175
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
In the case of transaction linked to sales orders it is
more appropiated to use the invoice partner related to the
sale order than its main partner.
After this fix the invoice partner of sale orders will be
used for transactions linked to it.
opw - 3212748
closesodoo/odoo#119962
X-original-commit: 6eaf11d1ac0d9fc3cd9d458e6ee1f27159216d40
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Currently, `website_sale` uses the same logic as `sale` to show the
product variant configuration.
This commit aims to separate this logic and let each module handle its
own product variant configuration.
task-3056806
Part-of: odoo/odoo#106511
Before this commit the public user did not have access to tokens or the
possibility of saving payment methods.
When receiving a link to pay the customer (even if not logged in) should
be able to use tokens saved by the parter of the document and also save
new payment methods. This is intuitively correct: as the possesor of the
link, the customer have rights to pay with tokens linked to the partner.
After this commit tokens linked to the partner of the document will be
visible to the public user and also the possibily to save payment
methods.
Task - 2799296
closesodoo/odoo#104472
Related: odoo/enterprise#34792
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The payment values in the Qweb context of sale, sale_subscription and
website_sale were computed separately, although there is a large common
basis. This split made it hard to communicate between modules and
generated a lot of duplicates. The new function `_get_payment_values`
in sales is now used as a common basis method for all sale_* modules to
get the common payment values.
closesodoo/odoo#107788
Related: odoo/enterprise#34922
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
When cancelling a quotation using the portal, the state will remain on
sent but the message given with it will be displayed on the chatter.
This bug is caused by the framework trying to display a cancellation
wizard.
opw-3084216
closesodoo/odoo#108476
X-original-commit: c662da9f1c8926cb2cebbb632a3621e2e26e2f36
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Cleanups and fixes/improvements extracted from another task
on the settings of sale.
* indentation
* code simplification
* privatize method not meant to be called by rpc
* double quoted strings for strings shown to users, single quoted for
technical strings
* translate onchange warning message
closesodoo/odoo#107897
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Rather than hiding all payment providers and payment tokens from the
payment form, a warning is now shown to the user if their company is
not the same as that of the document (SO, invoice, ...) they're paying
for.
task-2983985
closesodoo/odoo#100375
Related: odoo/enterprise#31424
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The note "Quotation viewed by customer" posted when a public user
accesses an order on the portal (with a token) was translated in
the "automatic" language, i.e. the website or user (or browser language).
This doesn't make much sense since log notes are not meant to be shown to
the user, only to the internal user(s) (/salesman).
This commit makes sure that the message is not translated in the website/customer lang,
but in the salesman or company language instead.
Task - 2836421
closesodoo/odoo#90318
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
There is an access error when using the product configurator in a mutli-
company environment
Steps to reproduce:
1. Install Sales
2. Go to Settings > General Settings > Companies and create a new
company
3. Go to Settings > Sales > Product Catalog and enable Product
Configurator
4. Switch to the new company
5. Go to Sales > Products > Products and create a new product
6. Set the product's company to the new company
7. Add the 'Color' variant on the product with at least two values
8. Go to Sales > Orders > Quotations and create a new quotation
9. Add the new product to the quotation, the product configurator shows
up
10. Increasing the number of product in the configurator will put the
total to 0 and the http request `/sale/get_combination_info` raises an
access error
Solution:
Pass the company in the context of the rpc call
Problem:
If we are in a secondary company, we try to acces the product of this
company from the default company in `price_compute`, which raises the
error
opw-2826227
closesodoo/odoo#91266
X-original-commit: 5477e1bce1a3791b39d0f6de9d382416fb4b6ebf
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
### Current behavior before PR:
The `product.template` model has a nice function `create_product_variant` that unfortunately expects its input to be in JSON.
### Desired behavior after PR is merged:
JSON decoding is moved into the controller, such that the function can be called as expected.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#88989
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
* Remove old unused parameters
* Move `backend_url` logic from qweb to python
* add comments, clean and simplify some code/logic related to portal
page of sale orders
Part-of: odoo/odoo#84644
* Rename decline route to make sure there won't be any conflict with
another controller method
* Use new translation API (pass string format params to the translation
method)
* always pass token param to _message_post_helper, it should correctly
manage any falsy value as parameter
* code cleanup
Part-of: odoo/odoo#84644
Before this commit the only way to modify the domain is to completely override portal_my_quotes/portal_my_orders.
Since this function is so big this is not clean/easy to do.
By creating a separate function we can simply override it and we can reuse the same domain in two places.
closesodoo/odoo#84886
X-original-commit: ff50844da0e4423372746e767f482a2a71148be4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit moves some code used in methods for `/my/quotes` and
`/my/orders` because the code was duplicated for the both routes.
So, with this commit, we can now call those hooks when we need this code
in another routes.
task-2648955
Closes#82379
In order to provide more transparency, we display any MOs linked to a
SOs via MTO linkage. This includes linkages made via reception report.
Part of Task: 2662730
closesodoo/odoo#79627
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Same as 5dde19c92ecee, sudo is not enough but the report needs to be
rendered with the user 1.
The access token proves the user has the access, the fact that he is a
portal, employee or public should not change the result
closesodoo/odoo#80491
X-original-commit: 66ab2ae213f05b055a032d0810de1de9334741ac
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The changes concern the following modules:
- sale
- sale_product_configurator
- website_sale
- website_sale_product_configurator
When optional products are enabled and a user adds an item to the cart, the
modal popup does not allow further modifications to the main product based
on its template. If the user wants to change the color or the material, they
have to close the popup, modify the product and open it back up.
The same is applied when Add to Cart is active, and the user cannot configure
the product at all after clicking the add to cart button.
This change will make it possible to change the product variants without having
to close the modal, and configure the product when using the "Add to cart"
button when it's enabled.
The added configuration step is needed for some cases like the following:
1. When adding a product that had variants directly from the /shop page before,
the first variant was added by default and configuring it was impossible without
explicitly going on the product's page and configuring it from there. This
behaviour made no sense, and it's the reason the "optional products modal"
(which should no longer be called that) is opened when the product is not
configured even if there are no optional products.
2. When going through the product's page, and there are optional products enabled
for the product getting configured, then it's nice but not necessary to be able to
configure the product further while choosing and configuring the optional products.
This doesn't add an extra step in any case, it just makes it possible to still configure
your product in the modal.
3. If there are no optional products, the configuration made on the product's
page is taken into account and the product is directly added to the cart without
opening the modal, which is the same behaviour as previously.
Only one modal is shown, depending on the situation:
- For the website flow, if the product is not configured and has variants or has
optional products (or both), a popup shows that allows for configuration +
choosing and configuring optional products.
- For the sales flow, there was already a configuration popup, so the optional
products modal is only shown when there are optional products and replaces
the first instead.
Some tests were adapted to function with the new product configuration modal:
- The steps checking for the text mentioned above are removed
- Triggers were adapted to the modal for products that were previously added to cart
with their default variant
- Various other small adjustments
task-2541663
closesodoo/odoo#73086
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
