Currently when the payment is initiated there is a message in
sale order for waiting for confirmation.
But when the payment returns an error there is no message on
sales order so it's not clear for the end user that payment
is still pending.
Related Task ID : 58741
- Improve warning message when user tries to create credit note
- Hide 'Active' column in Taxes/Currencies and added default 'Active' filter in Taxes
- Removed 'save this page...' under 'Account Follow-up Levels','Budget Management',
'Asset Management','Deferred Revenues Management' section in Accounting Settings
- Fixed margin between Cash Rounding checkbox and it's link in Accounting Settings
- Renamed action menu 'Confirm Payments' to 'Post Payments' for payments to make it
consistent with it's form view
- Hide payment acquirers config for non-adviser users and also restric editing access
rights for non advisior and employee user (only data read access rights on payment acquirers)
- Renamed Journal type from 'Sale' to 'Sales' and journals 'POS Sale Journal, Stock Journal,
Cash Basis Tax Journal to Point of Sale Journal, Inventory Valuation Journal and Cash Basis
Taxes Journal respectively
- Renamed the stat button 'Entries' to 'Items' for account assets form view
- Improved description and name of account_voucher module
- Improved Menu typo, Purchase Receipts to Purchases Receipts
- account_check_printing, hr_expense_check: made field storing check numbers character
instead of integer, integer field for check numbers shows check numbers as amount
(i.e., with thousand separator) on UI, which is wrong, hence replaced it with character
type field and a constraint to allow only numbers to be stored in it.
TaskID: 40157
Co-authored-by: Ravi Gohil <rgo@odoo.com>
closesodoo/odoo#21982
- Activate multi-company
- Create 2 S2S payment methods (Payment Flow: Payment from Odoo), one
for each company
- Connect as a regular user to `/my/payment_method`
The user has access to both payment methods, while he should only have
access to the method of his company.
opw-1920483
closesodoo/odoo#30558
Before this commit, in the config bar (Sales or Invoicing) when you configure a payment
acquirer, it was deployed in test mode, and not in production mode. Note that, the config
bar wizard asks for the production credentials.
Now, when you configure a payment acquirer, from the config bar, the acquirer is deployed
directly in production mode.
opw-1918412
closesodoo/odoo#30319
- The method `_get_available_payment_input` that returns the available
payments acquirers and the payments tokens for a specific user never
returns the payments tokens linked to a non s2s payment acquirers.
This is wrong, the payments tokens should always appears no matter
what are the acquirers' payment flow.
The payment flow is used only to specify where the customer should
input his credit cards details, either on Odoo or on the payment
acquirer's website (or popup).
Once a token is created, it is safe to process it since no credits cards
details are stored on the Odoo database.
closesodoo/odoo#30258
The field partner id is not a required field in payment transaction, and
we try to read its value in the dictionnary given to the create
function, so if a transaction is created without the partner_id, it will
raise a KeyError.
So to fix it, we only complete the pratner values on the payment
transaction if a partner_id is given.
Steps to reproduce the bug:
- Create a payment acquier PA with no journal
- Click on "Set payments" on your website dashboard
- On the wizard, choose "Custom payment instructions"
and select PA as Method
- Set a new bank name and a new account number
- Click on "Apply"
Bug:
A traceback was raised because no journal was set on PA.
opw:1916418
closesodoo/odoo#29378
- The payment transaction processing cron retrieves all the transactions
that need to be processed.
In some cases, it can causes issues when trying to process payments
that are being process by the payment polling page after returning
from the payment acquirer.
To avoid this concurrency issues, the cron will only process payments
that have been validated for at least 10 minutes.
closesodoo/odoo#29317
The link "Manage your payment methods" didn't work on the website because
the variable acquirers is a list of records.
This list has been created in function "payment_method" with the route
'/my/payment_method'
opw:1913299
closesodoo/odoo#29142
- When a payment is done through a `payment.transaction` the
communication should be the transaction's reference instead of its
invoices reference.
closesodoo/odoo#29187
* payment, website_sale
This commit solves the problem described in the issues mentioned below
by using the new system introduced by the parent commit.
That new system is even more integrated with website "animations" but
the mentioned issues' features are not yet converted to use those (this
will be a master task to make "Website Widget" be defined in portal to
use all of those integrated features). This commit however converts an
already protected behavior of website_sale using that "animation"
integration.
Closes https://github.com/odoo/odoo/issues/27976
Closes https://github.com/odoo/odoo/issues/28704
- Before this commit when a transaction failed, the code doesn't
rollback and continue to process the other transaction, thus creating
record that should be rollbacked.
closesodoo/odoo#28748
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
Improve various design elements in sales onboarding and config bar :
Onboarding :
- tooltip and done button
Company info:
- Move the incoterm field from company view to account settings.
Document layout:
- layout widget relabelling and reorganizing
- paper format as required
- added a Preview button
Payment methods and sample quotation :
- Style and relabelling
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
Barad Mahendra