As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
- Create a picking
- At creation, add a product and change the scheduled date
The scheduled date is reset to its original value when saving.
This is a standard behavior of the ORM for computed fields. Therefore we
simply forbid the modification of the scheduled date at creation.
opw-807572
In the case where:
create an invoice with payment terms that contains at least 2 term lines
Validate
create a refund by clicking cancel and reconcile
Before this commit, the refund move lines were wrongly created and reconciled with the invoice's move lines
After this commit, since payment terms are irrelevant on refunds, we set it to false and the problem doesn't raise
OPW 804752
The case: create an invoice of 2000 euros. Payment terms have been configured as:
1) fixed amount 150, 0 days after invoice date.
2) fixed amount 200, 10 days after invoice date.
3) fixed amount 200, 20 days after invoice date.
4) balance, 30 days after invoice date
Before this commit, when issuing a payment of 150 at day 0, that payment got reconciled with the balance line.
After this commit, the payment is reconciled with the right payment term line
OPW 805006
Take as example:
having demo user as expense manager
create with demo user an expense sheet for the employee linked to admin
on save, there was an access rights error for the write on mail_followers
After this commit, there isn't the error anymore,
since the computation of the field related is done with sudo
OPW 804740
On the payment confirmation page, when the payment is still pending.
Before this commit:
the user friendly message disappeared and a warning icon took its place
After this commit, the warning icon is prepended to the message.
OPW 787799
Step to reproduce:
- Go to 'Blog' > 'Blog Posts' in the 'Website Admin' module
- Select several blog.post on the list view
- Click on 'Archive' in the 'Action' dropdown
This will throw a server error since write() is overriden for blog.post and
do an ensure_one()
This commit closes#22208
-> Move a button into its wizard and not in the void
-> In the sale order, set the default value for require_payment related to sale_portal_confirmation_options.
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
If the user has no Zip code, country or city, authorize refuse the payment, but Odoo doens't show any error.
The commit invite the user to log in in this case or to fill his missing information
The different fields weren't correctly checked on a payment form. This commit improve the error messages and display it for each field. It adds too a verification on the fields in the case of the field are filled automatically by Firefox on a refresh (F5).
- Set the OS to a GMT- timezone (e.g. 'America/Los Angeles')
- Set the format of the date to '%d/%m/%Y'
- Go to 'Account > Adviser > Journal Entries'
- Type '02-01-2018'
The suggested date is 31/01/2018.
Setting the moment object as UTC will lead to a conversion of the date
to the OS timezone when calling `toDate`, e.g.:
Mon Jan 31 2018 16:00:00 GMT-0800 (PST)
UTC should only be used in case of datetime, not date.
opw-803466
When encoding global leaves, we put the timezone of this particular
leave to False, which raises an exception when given directly to pytz.
Simple solution is to pass 'UTC' in case we receive False. This
behaviour might be improved in master later.
Having it in INFO should be sufficient for its purpose, and will avoid
impacting all CI builds done on a system that does not have the lib
installed.
For the record, this is not a hard requirement because the lib was not
available in Debian stable packages at the time of release. It is only
enabled on demand for those who want the feature and can install it
manually.
Also slightly improved the message.
Fixes#22426Closes#22459
`precision_get` return digits, so use `precision_digits` in the call to
`float_is_zero`.
steps to reproduce:
- set the digits of product unit of measures to 0
- try to scrap something
- it'll fail because the default value of product_uom_qty is "0.0"
A `default_get` for a x2many field can return a new list of commands for one of
its x2many field, like
[[0, 0, {
'groups_id': [[6, 0, [1, 2, 3]]],
}]]
where [1, 2, 3] is a list of existing ids.
This use case was not correctly handled by the BasicModel because
`_makeDefaultRecord` was not recursive.
Closes#22401
Odoo Translation Bot