This fixes a bug introduced by commit f650522bbf
(related fields should not be copied by default). Inherited fields are a
particular case, and given the implementation of copy(), they must be copied if
their original field is copied.
The test on copy() in test_orm has been modified to show the bug.
This helps fixing old-api onchange methods with a record id as a parameter.
Browsing this record id may be problematic, since it reads the record in an
environment with an empty context. This is really problematic when the record
is a new record, because such a record only exists in a given environment.
When using %(date)s in the follow-up text in the follow-up levels configuration
the date was formatted within server date format
instead of the partner language date format.
Closes https://github.com/odoo/odoo/pull/5168
The onchange() on new records processes fields in non-predictable order. This
is problematic when onchange methods are designed to be applied after each
other. The expected order is presumed to be the one of the fields in the view.
In order to implement this behavior, the JS client invokes method onchange()
with the list of fields (in view order) instead of False. The server then uses
that order for evaluating the onchange methods.
This fixes#4897.
The module analytic_user_function allows to define a specific product
to use, when creating timesheet activities for a specific employee
with a specific contract
Nevertheless, the product was not set accordingly to this feature
for the first timesheet activity, because,
when initilialing the timesheet line,
the on_change_account_id, which returns
the product to use according to the user and contract, was called
without passing the user.
Besides, by default, on_change_account_id does not have a user_id parameter,
this parameter is added by the module analytic_user_function, overriding
this onchange, and adding a new user_id parameter (which is not a good pratice).
We therefore use multi_on_change_account_id, which allow to pass the user_id,
within the context
A record rule exists on currencies but not on rates.
If creates multiple currencies with rate = 1, we could fetch the wrong one in
the search and get a security exception while trying to convert rates.
Fixes#3323, opw 626353
The mechanism to determine the table and column names of new-api many2many
fields only worked for many2many fields created from old-api many2many columns!
This fixes#4851.
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
Most pop servers don't perform deletions until QUIT. If for some reason
the process is killed while fetching a large quantity of messages, the
quit method isn't invoked, while the commit method has been. We may thus
end up with duplicated messages the next time we try to fetch. It therefore
helps to fetch the messages in small subsets and call the quit method between
those subsets.
In 7.0, prevent changes in activities of validated sheets was done thanks to the constraint
_check_sheet_state.
In 7.0, python constraints were checked at each write operations
whatever if the fields on which the constraint is were altered or not
This is no longer the case in Odoo 8.0: The constraint is checked
only if the fields on which the constraint is are altered.
As this specific constraint must be applied anytime, whatever the altered fields,
we now do this constraint check in the "write" method.
Besides, it was already the case for the unlink method.
opw-627415
Once a timesheet confirmed, the activity hours should not be modified,
for any reasons.
The constraint _check_sheet_state prevents to modify activities
for confirmed timesheets, but does not prevent the addition
of new activities within the current, but confirmed, timesheet.
opw-627415
fixes#5128
Raphael Collet
Stéphane Bidoul
Olivier Dony
Parthiv Patel
Serpent Consulting Services Pvt Ltd
David Monjoie
ma78nee
moylop260
Josse Colpaert
Denis Ledoux
Julien Laloux
Alexandre Fayolle
Anton Chepurov
Antony Lesuisse
Martin
Leonardo Pistone
Joël Grand-Guillaume
Martin Trigaux
Alexis de Lattre
Kiril Vangelovski
Csaba Tóth
Adrien Peiffer (ACSONE)
Nicolas Piganeau
Julien Legros
buke