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
When installing a payment acquirer from the kanban view, this would by
luck display the form view correctly.
But if we go back to the listing then forward to the form view, things
go awry.
This is because the listing action views have not been updated after the
module installed, this worked at install because we loaded a new action.
This commit change the action so when installing a payment acquirer from
the kanban view, the view is simply reloaded.
opw-786454
closes#21757
* add a method computing available acquirers and payment tokens for a
given partner and company. Those data will be used notably in customer
portal when displaying the payment form;
* raise if no partner_id set in s2s process. Indeed this field is
required but values come from a dict. Current code raises an error
about None being converted to Int instead of giving the real error;
- 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)
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
- 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.
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
Since subscriptions only accept tokenizable (credit-cards and such)
payment options, we must use the token_implemented field to filter out
non-tokenizable payment options (such as wire transfer) and because
token_implemented is a computed field, a search function had to be
created
Rev. cf1df16aea introduced new callback
fields with restricted access. The lazy hash generation in create() was
however causing access errors for manual transactions created by users
who are not administrators (e.g. Accountants).
Those manual transactions do not typically need a callback, but checking
the presence of the callback requires a limited sudo() context.
Similarly, the execute_callback() method may be called for a manual,
non-admin transaction, and should not do anything if there is no
callback, instead of crashing with an AccessError.
The generation of the hash and execution of the callback should be done
with a normal environment, though, as these must only be used for
transactions run by the system.
opw-747536
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 a constraints about authorized state for tx and authorize feature
available on acquirer;
* order acquirers first by publish, then sequence then name;
* add a sequence on some provider data and use a default to have some
popular acquirers first;
* use update instead of write in an onchange;
* 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;
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
SIPS payment has two limitations:
- A payment reference can only be used once, even if the payment was not
proceeded
- A payment reference can only contain alphanumerical characters
These limitations do not fit the payment process which:
- Reuses existing transactions
- Introduces a `-` character when creating a new transaction for the
same order.
First issue is solved by an ugly hack since there is no link module
between `website_sale` and `payment_sips` in order to override the
behavior of `sale_get_transaction`.
Second issue is solved by modifying the character to `x`. In this case,
we could consider overriding the method `get_next_reference` in
`payment_sips`. However, this method is called before the creation of
the transaction, and we should do a crappy workaround using the context
to get the `acquier_id`.
opw-728209
Allow to configure the bank statement import mode from kanban
When doing a manual journal entry, don't show the maturity date
Removing Issued total, using credit instead (less code, more
useful to have due amounts, instead of overdue)
Creating a bank, set a name 'BofA Current' and an
account number (that way, the account.account is based
on name)
Settings Wizard & menus: better sentences
Statement CSV Import: installed by default (it
does not add any menu)
remove use_in_payment: complex field, only
used for a default value
Small code cleanup
[IMP] sale: moving order date to secondary tab (strange on a quotation)
callback_eval is currently a code string that is evaluated directly
at payment confirmation. This commit changes it to have parameters
on the record and method to call on it. Moreover a hash done once at
transaction creation ensure that a modified transaction does not allow
to execute code on other records.
The payment reference of a S2S transaction has the given format:
'PAYMENT-9-170110_200204'. However, the reference is too long for some
providers such as Authorize (limited to 20 characters).
We make the reference less verbose as a first step to solve the issue.
However, case-by-case solutions will need to be found since the
reference depends on the id, which will ultimately grow.
opw-704615
fda-odoo