Online quote now uses JS code from payment module in order to make online
payments. Front-end template is updated to use o_payment_acquirer_button
generic class for payments and data is added to be managed by payment.js.
This allows to remove some strange code parsing the url to find the order
ID and token instead of using rendered values.
A payment controller is removed because it was only a shortcut to another
one. In transaction controller token parameter is renamed to access_token
to avoid confusion with payment token and match the payment and website
sale naming.
Online Quote controller now uses tools method from sale_payment module
like website_sale. This way it is now standardized and moved out of
controllers that should not perform so much model-level computation.
This commit adds tools method in sale_payment related to sale order
confirmation, token and transaction management. Purpose is to be able
to use them in frontend sale module like eCommerce and Online Quote and
have it standardized at model-level instead of done custom in controllers.
JS code managing transaction creation through acquirer 'Pay Now' form
button is improved in order to be less website-sale dependant. It now
takes parameters for access token and URL to call in Json. Class used
to bind JS is now o_payment_acquirer_button in order to be more generic.
eCommerce module is updated accordingly. Future commits will probably
make Online Quote (website_quote) use it.
Indeed this code is difficult to understand and uses unnecessary
variables. Both confirm_so and generate_and_pay_invoice methods now work
on payment.transaction records as they belong to that model. Finally
less code is put in the try/except of confirm_so to avoid hiding real
errors and issues.
One interesting thing would be to correctly manage so confirmation errors
and mail sending errors. This is currently not done and will maybe be
done in future commits.
Access token field is moved directly in sale module. Indeed future commits
will improve customer portal and access tokens will be used in other module
than website_quote. This commit already moves the field.
Moreover some strange code in website_sale already uses access_token even
if it does not exist in that module. Moving the field solves that issue.
Finally so_token defined in stripe is renamed to access_token to have the
same naming through all addons.
Move sale and payment bridge code into its own module. This commit mainly
moves (and reorganizes without changes) code from website_sale related
to payment and SO confirmation.
Only change is that payment_acquirer_id field on sale order is now a
related on transaction.acquirer_id . Indeed in website_sale and
website_quote both values were written but only managing transactions
and getting its acquirer is more efficient and ensure values are coherent.
JS part controlling payment form management is moved directly into
payment to reuse later on in future commits. Probably.
Purpose: separate and locate website code for main addons in their
correct module. This commit targets accounting related customer portal.
This commit adds a new bridge module between website and account. It
contains code related to website portal of invoices. It was located
in website_portal_sale but this one should only be the quotation and
sales portal.
A dependency from website_sale to website_account is added to ensure the
behavior and available features of eCommerce are not impacted by this
commit.
No code modification is performed in this commit except one unnecessary
less rule. It contains only code move.
Instead of checking that the day short name is effectively Sat or Sun
it now checks that it is the saturday or sunday based on weekday. It is
located in a method to ease inheritance or implementation of specific
behavior based on some calendar if necessary.
Closes#17294 .
Purpose
=======
Ease payment setup & flow of ecommerce
- In Odoo, we have 3 ways to sell:
- sales -> invoice is needed when you issue quotations
- eCommerce -> invoice is mostly for B2B but is part of the flow in any case
- PoS -> invoice is mostly for B2B. It's an option
-> make invoicing an option in ecommerce (still working but invisible)
- Config of payment acquirers is tough to understand: remove order confirmation
- the invoicing process depends on the company, not on the payment acquirer -> simple invoicing option in ecommerce settings
- capture manually: only for authorize.net! Somehow it shouldn't be visible for other acquirers
- terms are confusing
- payment method: payment method is something else in accounting payments. -> rename to payment acquirers
- transaction: the difference with payments is not obvious -> rename to payment request
Specification
=============
- New module to add invoicing fields, buttons and menus: account_invoicing -> hide invoicing stuff when starting with eCommerce (not Sales app)
- new setting in website:
- keep behavior of current setting
- if automatic generation of invoice is checked (default value), an invoice must be generated, validated and reconciled when the order is confirmed
- If "Invoice what is delivered (manual)", users will create the invoice manually from the order.
- tooltip: Choose the automatic mode if you use to issue an invoice whenever an order is placed. The manual mode allows you to invoice based on what is really delivered. That way you can invoice in several steps, etc. The mode selected here applies to any new product created but not to products already existing. If you want to invoice delivered quantities, you must update the invoicing policy of those products.
- New primary button "Mark as Paid" on SO if status = quotation sent and payment acquirer provider = wire transfer or manual config
- when you press "Mark as Paid" -> mark payment.transaction as done.
- easy way to cancel payment -> when clicking Cancel Order button: reset the transaction to Pending, break the reconciliation receivable (=invoice) / payment, cancel the payment with an opposite entry. That way everthing comes back to initial state.
- when a payment.transaction is 'authorized' or 'done' -> confirm the SO
- when the transaction is 'done' -> register also a payment in the payment journal set on the payment acquirer (mandatory field, see next item).
- must work for any payment acquirer, even if provider = wire transfer or manual configuration
- restructure options of payment acquirers:
- replace Order Confirmation by:
- Payment Journal
- existing m2o (journal_id), make mandatory, only show account.journal whose type = bank + context when you create a journal from the field, default value = Bank, display only if account_invoicing is installed
- tooltip: Payments will be registered into this journal. If you get paid straight on your bank account, select your bank account. If you get paid in batch for several transactions, create a specific payment journal for this payment acquirer to easily manage the bank reconciliation. You hold the amount in a temporary transfer account of your books (created automatically when you create the payment journal). Then when you get paid on your bank account by the payment acquirer, you reconcile the bank statement line with this temporary transfer account. Use reconciliation templates to do it in one-click.
- Capture Amount Manually [ ]
- only visible if acquirer type = Authorize.net
- tooltip: Capture the amount from Odoo, when the delivery is completed.
- must be compatible with "Create Invoice Automatically". -> The invoice must be created when the payment transaction is "done"
- Specific Countries [ ]
- if checked show the country field just below
- tooltip checkbox: Make this payment acquirer available for customers of specific countries.
- tooltip Countries: If you leave it empty, the payment acquirer will be available for all the countries.
- Add Extra Fees [ ] move up the fees fields
- Relabelling:
- Payment Methods -> rename to Payment Acquirers (menu items, views, etc.)
- real payment methods already show up in the Register Payment modal of invoices.
- Transactions -> Payment Requests
- "Transaction" is too close to "Payment". People think it's the same. With payment request, it makes think about a process: payment request -> payment
- Add a "Payment Requests" stat button to SO form to see all the payment attempts + show the status in this list view.
- if only one payment request, display it in form view
- + remove payment method + transaction fields below the SO total
Additional remarks:
- mark as paid button only when you can do it
- mark as paid should confirm the order (+ hide Confirm button)
- invoicing settings: faut un peu changer le truc pour séparer la génération automatique de la facture du mode de facturation des produits
- hide radio options when Invoicing option is not checked
- to hide if account_invoicing is not installed:
- invoicing options in product form
- SO invoicing status in list view
- invoicing status in SO form
- invoice link once order paid + invoice notification in the SO chatter + hide mark as paid button if already done
- create invoice button in SO
- orders to invoice in website dashboard
- in automatic invoicing > mark order as paid > cancel order > reset to quotation -> no way to record the payment again
show MARK AS PAID in draft quotation status IF payment transaction is set ?
Purpose
=======
The field journal_id on a payment.acquired is required on the view. The only issue is that the journals cannot be created before having installed a localization. When the payment acquire module is installed before the localization, the journal id is not set on the payment acquire and it's impossible to make a call to `write` (For example publish the acquire)
Specification
=============
When making a write or a create on a payment acquire, udpate the journal_id with a default value if not set.
PURPOSE
=======
The field auto_confirm is complicated to understand for common users. Furthermore, on of its options is only useful for authorize module.
SPECIFICATION
=============
Remove the auto_confirm field. The destinies of its options are the following:
- none: Simply disappear.
- authorize: Become capture_manually. It has nothing to do with the auto_confirm field has it's related to the autorize module (And could be extended to other payment acquirers too).
- confirm_so: Remove it. Will be automatic, and we will always validate the sales order and generate the accounting entries on acquirer validation.
- generate_and_pay_invoice: Is linked to the journal_id. The field journal_id is always set and we will use it to validate the sales order and generate the accounting entries on acquirer validation.
Bonus: website_sale: Allow to create/validate invoice automatically on `Mark as Paid`
Purpose
=======
Ease payment setup & flow of ecommerce
In Odoo, we have 3 ways to sell:
sales -> invoice is needed when you issue quotations
eCommerce -> invoice is mostly for B2B but is part of the flow in any case
PoS -> invoice is mostly for B2B. It's an option
-> make invoicing an option in ecommerce (still working but unvisible)
Specification
=============
Hide the menuitems of account, and add a module account_invoicing that will display them.
Hiding the Sales root menuitem isn't sufficient to hide all the menuitems from the sales module.
Example:
1/ Install Ecommerce, you don't have any menuitems from sale as sales_management isn't installed
2/ Install CRM, the root menuitem is activated by the sale_crm, and all the menuitems from sales are displayed
Specification:
Add the attribute active=False on all the menuitems from sales
Activate them on sale_management
This attribute will be used in the next commit to hide by default account menuitems in the account module to finally display them in the account_invoicing module.
Without this attribute, we should create the menuitems with the <menuitem> tag and after that make them inactive by using a <record> tag
PURPOSE
=======
Correct wrong placeholder
SPECIFICATION
=============
1. On SO, field "Note", replace the current placeholder by "Setup default terms and conditions in your sales settings ..."
2. On PO, field "Notes", replace the current placeholder by "Define your terms and conditions ... "
When cloning a snippet section thanks to the editor, the associated
snippet options' `on_clone` methods are called. Now these methods
receive a new argument `options`. The option this commit introduces
is the `isCurrent` one. It allows the method to know if the snippet
section it is associated to is the one that was cloned or if it is a
child of the one that was cloned.
This is useful to solve a known bug when cloning elements which have
bootstrap columns:
- When one column is cloned we want it to lose its col-*-offset-*
classes so that the offset is not duplicated (only the column).
- When a container with column children is cloned we do not want
these column' offsets to be removed (we want the whole cloned
container to be the same).
Some default website menu were not marked as active when landing on
their associated page, e.g. clicking on "Blog" loads the blog page
but the "Blog" menu is not marked as active.
This was because of slugified URL. Indeed, for the "Blog" menu for
example, the URL "/blog/1" redirects to the "/blog/my-super-blog-1"
URL.
Introduce a new snippet to show the company team.
This commit also introduces a new classe "s_no_resize_cols" to put
on a .row element to prevent the size and margins options to be used
on the .col-* children. This allows to build some complex layout without
having a deep hierarchy of snippet options.
Portal users do not have access on invoices or invoice lines. However when
viewing an online quotation in website_portal_sale some computation is
performed based on invoices and invoice lines. We therefore iterate on
invoice and invoice lines as superuser as we do not want to grant any
additional access on those models for portal users.
When choosing a payment acquirer or a delivery provider there is a link
allowing to directly jump in the backend to configure them. It has been
introduced at 6c2535b9b6.
However it is displayed for every user going through the checkout process.
This commit limits it to group_system. It seems a better idea to not show
it to everyone as they don't have access to it anyway.
Indeed, running the testsuite is not supported in multi-process (worker/pre-fork) mode, for multiple reasons: no multiple/concurrent execution of tests, necessity for in-memory cross-request statefulness (test cursor), etc.
We have no plan to work around these issues, as there seems to be no strong use case.
Our testsuite is mainly focused on the business/framework aspects, and not scalability/deployment aspects - which would require a much more complicated test infrastructure.
In this commit, we improve the behaviour of quick creation in grouped kanban views. The issue was that the quick create widget was removed when the user click somewhere else, even if the user added some text. For example, the problem could be seen in the kanban view for the tasks.
In this commit, we simply keep it around if there is a non empty text.
Clicking multiple times on 'Create' (in main list views) or 'Add an
item' (in o2m lists) might create invalid rows (i.e. rows with
required fields unset).
Creating a new record requires two sequential RPCs: a default_get
and an onchange (only if there is an onchange of one of the
record's field). When clicking twice to create a new record, that
sequence of RPCs is done twice in parallel, after unselecting the
current row (i.e. saving it if it is valid). However, in both
cases, there is no line to unselect yet (as both operations are
done basically simultaneously). When the first onchange returns,
a first new record is added to the list. When the second returns,
the second one is added and takes the edition, leaving the first
one, invalid, in the list.
This rev. ensures this doesn't happen by preventing concurrent
record creation.
... before saving a line.
Suppose that we have an editable list with one required field
(e.g. many2one) with an onchange. We add a record and select a value
for the many2one. Before the onchange returns, we click again on
'Add an item'. If we don't wait for the onchange to return before
unselecting the row (i.e. before saving it), a confirm dialog asking
if the changes can be discarded opens, because the line isn't valid
yet. This could easily be reproduced on the sale_order form view,
with some throttling.
This rev. ensures that we wait for the onchange to return before
saving the line, and thus before creating a new line.
In a slightly too naive way, we apparently tried to improve the
parse_float method while rewriting the new views. This was done by
using a regexp to match all occurences of a thousand separator.
The way the regexp was built was fine, until the thousand separator is a
'.', which, if used as a regexp, matches all characters. Also, sadly,
'.' is not so rare as a thousand separator...
When creating a vendor bill from a PO, the payment term configured in
the PO was lost due to function _onchange_partner_id.
When creating a vendor bill, the field payment term was invisibile if
there was no payment term set on the vendor.
opw:744714
When a ´default_order´ is set on an embedded view for a x2many field,
the sort was only applied server-side, after saving the record. After
adding a record in a x2many, the records were thus not correctly sorted.
We reintroduce here the client-side sort after the x2many modification.
Thibault Delavallée