In the tree view, the domain for the field `analytic_account`
was already
`[('type','in',['normal','contract'])]`
It's therefore normal to apply the same domain for
this field in the form view.
Closes#2733
When the view form is loaded passing by the kanban list, the kanban
dataset data could be loaded after the view form is displayed.
When going manually to the view form, the human is usually enough slow
so the dataset ids are already loaded, but when loading directly the
view form (for example an "Edit" link from a record on the website or a
refresh) it can not be. For example on runbot the issue happened more or
less 50% of the time, and on localhost 90% of the time.
closes#7525
opw-642636
If too many tags (or too long tags) where present in a many2many tags
widgets, it could go over the field and cover other thing in the UI.
Now the field size expands with the content (and in a way it is more
visually similar before and after 'Edit' so it is nice).
closes#7579
opw-644236
When name_search is called with an extra domain
filter (args) and a pattern (name) containing
multi-level accounts, such as `A / B / C`, only
the last account (`C`) has to match the domain.
The intermediary parent accounts do not have to
match.
The domain was previously applied for each parent
in the lookup. This prevented searching for
multi-level accounts or copy-pasting full account
names whenever a domain was present and did not
match every account in the hierarchy.
In case you customize these emails, you do not want
to have them reset when you update the module (-u)
Same thing for the two default value in this file
for event.type
opw-644082
The field property_account_position is added by the view
account.view_partner_property_form which is restricted to users with accounting
rights. If tired to access the view, the inheritance made on l10n_ro would fail.
Fixes#6952
In the receipt report, the quantity decimal precision
was hardcoded to 0, while it should use the decimal
precision from the field definition.
opw-644507
There is no easy way to edit the values sent
to newly generated users from oauth_signup.
In some cases,
the mapping from an oauth provider can be different.
* ex: login is something other than email
In other cases,
there are additional fields in res_users added by a module
* ex: firstname and last name in `partner_firstname`
This factorization allows modules inheriting from `auth_oauth_signup`
to alter values sent to the copy of Template User.
This means smaller changes to the default behaviour
and the ability to properly inherit
(multiple times if needed)
this module without losing needed behaviour.
Closes#2355
Not just when coming back from the payment provider to the
payment validation route `/shop/payment/validate`.
Otherwise, if you do not come back from the payment provider
page, that you quit just after having paid but just before
being redirected to Odoo, you do not receive the email.
The change within the `sale` module, while this issue concerns
`website_sale` only, has been accepted because this is a mechanism
that could be used by other modules.
opw-644348
In the aged balance report, the reconcile entries are excluded
except if the reconciliation date is greater than the date for which the aged balance report is requested.
But this exception should never include opening entries.
opw:643172
The amount to pay must be sent without comma to ogone.
e.g., for 66.99 EUR, the amount sent must be 6699.
To do that, we simply applied 66.99 * 100, which
seems rather good.
However, due to the fact how floats are handled in computers,
`66.99 * 100` returns 6698.999999999999
and
`int(6698.999999999999)` returns 6698
while we expected 6699
Using `float_repr` with `0` as decimal precision
instead of using `int` solves this issue.
`float_repr(6698.999999999999, 0)` returns 6699, as expected.
The valuation wizard is based on stock moves and currently only takes into
account the moves which have different companies in source vs destination
locations.
This is a problem because all user-created locations have a default company set
to the user's company, even the "virtual" ones. For example in the demo dataset
visible on runbot, some supplier locations have a company set and some don't.
So we have to make sure to include every move coming from/going to
outside locations based on the locations's type too.
Closes#7530
Method action_produce does not support the case where the same product appears
on multiple lines. We do this to avoid major changes in a stable version.
opw-644093
When building a new suvery, and sending invitation
trough private emails, it wasn't possible
to fill the survey from the link sent
if you were not logged as the user who sent
the invitation, or as a survey manager
opw-644210
Fixes#7486
The menu entry in Warehouse > Current Inventory Valuation is a shortcut to the
same results as the wizard in Reports > Warehouse > Valuation. However when
using the "current valuation" menu entry, the list is given without grouping by
product and location, so it's basically just a glorified list of stock moves
that no Warehouse manager is going to understand.
Let's just add the same default grouping to let the results make sense.
Closes#7531
A log analysis showed that the normalized query below was executed very often
with a slow explain plan using a seq scan.
```sql
SELECT move_id, date
FROM account_move_line
WHERE journal_id = <journal_id>
AND period_id = <period_id>
AND create_uid = <user_id>
AND state = 'draft'
ORDER BY id DESC LIMIT 0;
```
This query is called in the _default_get of account.move.line to find the last
unbalanced move line.
The existing index can be improved to cover this query as well, showing an
impressive improvement of the explain plan as explained here:
https://github.com/odoo/odoo/pull/7430#issuecomment-119521031Closes#7430
When a PO is created automatically from a procurement, the fiscal position is
not chosen correctly. We need to choose the fiscal position in the same way if
the PO is created manually or automatically.
Follows commit 1062905acbFixes#3863
opw-643916
It is necessary to round the quantities with the appropriate precision. Indeed,
since onchange_quantity and onchange_uos_quantity trigger each other indirectly,
it is quite easy to fall in an infinite loop if the uom and uos precisions are
different.
Follows commit 6e346f0adb
opw-643651
The behavior of the datetime widget was to focus in the field every time a date
is chosen. This causes an issue if the datetime widget is called from an
editable list. Indeed, the list editable will consider that the value has been
set, and therefore the value will not be changed anymore if the user choses
another date.
The new behavior is to put the focus only when the date picker is hidden,
therefore the editable list will consider the value set only when the selection
is done.
opw-644062
Fixes#7463
Martin Trigaux
Maxime Chambreuil - http://www.savoirfairelinux.com
Nicolas Lempereur
Odoo Translation Bot
Olivier Dony
Christophe Simonis
Denis Ledoux
stijnh92
Sandy Carter
Lorenzo Battistini
Jose J. Duran
Goffin Simon
Lionel Sausin
Nicolas Martinelli
Guewen Baconnier
Holger Brunn
Erwin van der Ploeg
EL HADJI DEM
Leonardo Pistone
Samus CTO