-> 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
- Create a product with 'Service Tracking' as 'Create a task in a new
project'
- Create a SO with this product, validate
- In the created task, add a timesheet line
The delivered quantity is not updated on the SO.
In method `_analytic_compute_delivered_quantity`, the item is skipped if
the field `product_uom_id` is not set on the analytic line. However,
`product_uom_id` is set in method `_timesheet_postprocess`, which is
called after `_analytic_compute_delivered_quantity`.
Therefore, we move this part in `_timesheet_preprocess`.
opw-805533
In any piece of code, execute the following:
```
self.env['account.config.settings'].create({})
```
It overwrites the values of `fiscalyear_last_day` and
`fiscalyear_last_month` to 31 and 12.
Setting a default value on a related field will automatically write
these values on the related.
opw-805205
Rev[1] fixed a bug where the order inside of the recordset could trigger
side effects by merging move when creating the extra moves. However,
after the patch, `moves_todo` contained moves that should be backordered
(with no quantity done). This commit fixes this oversight.
[1] b95cabef0bFixes#22440
When words are too long this may break out of a kanban tile and getting
everywhere.
This is not wanted and the content should be:
- hidden if overflown or
- long words should be wrapped or
- too long content should be ellipsed
The ellipsis is probably the best but this would affect the current
behavior (we would have to specify a max-height which unexpectedly
may be bothersome to currently existing data).
So breaking long words has been choosen in this change.
opw-806278
closes#22435
In the case where:
1- Do an order on the pos selling a product A (amount = 10)
2- Do another order returning a certain quantity of A (with a quantity < 0)
3- Do a third order selling something else (amount = 5)
Before this commit, the account move lines of the payment move and of the sale move of operation 2 weren't reconciled
This was because the credit to the receivable account of the return was reconciled with the debit of the first operation,
leaving the debit of the payment of the return alone
(i. e. the lines number 1 & 3 & 5 were reconciled together, instead of 1 & 2 & 5, and 3 & 4)
We end up in a situation like this (at validation time)
RECEIVABLE
D | C || OPERATION | Line Number
----------------------------------------------------------------------------
15 | || (1 & 3-Engaging Sale) | 1
| 10 || (1-Payment) | 2
| 10 || (2-Engaging Return) | 3
10 | || (2-Payment Return) | 4
| 5 || (3-Payment) | 5
After this commit, we reconcile the returns for each order before reconciling other transaction chains
The fix is limited in its scope as the automatic reconciliation for the pos transaction is fairly recent
and a "nice to have"
OPW 787298
Rev. 5140d3d1 fixes the google_drive override of the Sidebar in
saas-16. The test specifies param 'sidebar: true', so that a
sidebar is instantiated by the FormView. This param has been
renamed to 'hasSidebar' by rev. 32b8cec in master, so the test
broke when rev. 5140d3d1 has been forwardported to master, and it
thus needed to be adapted.
In a grouped Kanban view, when the user clicks on 'Load More' to
load more records of a given column, then opens one of those
records in the form view, and goes back using the breadcrumbs, the
formerly loaded records should be reloaded, so that the user does
not have to click again on 'Load More' to get to the position he
was previously.
This rev. increases the limit of the given column when the user
clicks on 'Load More' to force this behavior.
Before this rev., the group_by specified in the action context was
completely overridden by the group_by specified in the search view,
even if it was []. In other words, it was completely ignored.
Moreover, it was only took into account (before being overridden)
at the first load of a view, not at reload.
Let's assume an action with a 'group_by' specified in its context.
Unless another groupby is specified in the search view, the action
groupby must be used. For list views, it was only working for the
first rendering of the view. As soon as it was reloaded, the action
groupby was lost.
For instance, go to Project, click on a project in the dashboard
[the action has 'group_by': 'stage_id' in its context], switch to
list view [the list is correctly grouped by 'stage_id'], reload by
clicking on the view switcher -> the view isn't grouped anymore.
It was actually working by chance on other views because they have
specific handling of the groupby (e.g. the kanban view allows the
attribute 'default_group_by' on its arch), but by default, the
action groupby must always be used at each load/reload if there is
no other groupby specified.
This rev. restores the behavior of saas-15, before the new views.
fda-odoo