The `pre_msg` field was removed from the payment process in commit
14081b848f. We hide the field since it is confusing for end users. A
proper refactoring will be done in master.
opw-1849413
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
- The payment template is overwriting the return url which caused it to be never valid.
This is mainly used by payment that uses 3D Secure.
If the return_url doesn't exists, then the customer is redirect to '/' which is not what we want.
If the payment doesn't use 3D Secure, then the controllers that handle it may (and it is always the case) redirect the url to a hardcoded url inside it.
- On 'website_payment/pay' if the reference contains a '/' the payment will never succeed.
It is due to the fact that in the template "payment.pay" were setting "prepare_tx_url" and "form_action" using this reference.
But having a '/' in the reference breaks the URL to call to create a transaction.
So when creating a transaction (or even paying in S2S) the payment never succeed and returns a HTTP 404 error.
The generic payment form introduced in 11.0 has changed the way we collect payment and so does the code.
The route /website_payment/pay hasn't been changed to support the new payment form.
This commit fixes this.
It also fixes a bug for when a customer tries to create two transactions with the same reference.
WARNING: To avoid breaking any configuration in stable (11.0), the template payment_confirmation_status has been replicated in each module.
They must be removed before a forward-port in master
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
Purpose of this commit is to ease the use of the payment widget and
avoid having to perform too much custom code in the various routes used
when doing payments :
* when instantiating the widget give him its parent element data so
that parameters given when calling the payment form template are
automatically present in the widget options;
* support more parameters when calling the route for form-based acquirers
including access_token, URLs and callback method;
* when doing a form-based payment a call to a JSON route returning the
rendered form is done. Payment widget now uses all data from that
form including the URL of the acquirer website. This way form-based
acquirers are really dynamic and values update is easier;
* remove hidden display of form-based acquirers as all data come now
from the called JSON route that returns the form;
* add a warning about partner-id not being set as it is an issue some
people may encounter;
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
- Added the support of form payment.
- Fixed payment form's errors not being displayed.
- Fixed a crash when paying on e-commerce with a saved token.
(dev commit, need to clean the code)
- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
Customer portal controller and templates contained in website_payment
module are moved to payment. This module now uses the customer portal
defined in portal module and most of website_payment code is moved
to payment.
website_payment now contain code really related to website, such as
payment acquirers configuration for website.
This commit adds a new bridge module between account and payment. This
module is used notably to display payment related information on account
customer portal. It currently holds only a template but future commit
will add new features related to invoice payment on customer portal.
As already done for sale, customer portal for account is moved to account
module directly. Account now depends on portal module and website module
is not necessary anymore to display the account customer portal.
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
When registering a payment token, validating it using a payment of a small amount followed by a refund
allows ensuring that the method is valid (i.e. checksumming the card number simple ensure the number
is valid but not that the card exists). This commit introduces a generic approach that must be implemented
for each acquirer that has tokenization support. This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
payment_ogone: add support for tokens validation
-added tour for invoicing
-allow to set easily the number of the first invoice/bill/refund of a journal, from the invoice screen
-small usability fixes and refactoring
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
=======
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`
* add provider, related on acquirer_id.provider, in order to display
certain piece of information on tx depending on their provider;
* better tx form view and partner address display;
* remove unnecessary notebook on tx form view as it is not used;
* rename Payment Acquirers menu into Payment Methods, easier to
understand;
* acquirer kanban view improved to install / activate / configure them
depending on their state;
* be able to publish / unpublish acquirers without having to wait for
website_payment to add a button;
Indeed as transfer transactions are always pending and independant of
any callback, it is not necessary to see credentials, auto confirmation
settings and error / cancel / done messages.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
Nicolas Martinelli