Ultimately, it seems that sending the value of readonly fields
when saving is not such a good idea. Suppose that there is a
computed field displayed as readonly in a form view. This field is
computed from other records, e.g. from a one2many field which is
editable in the form view. Finally, the inverse function of the
computed field creates the one2many records. If the user adds some
records to the one2many, then saves, the readonly computed field's
value is sent to the server as well, and thus the inverse function
is executed, which isn't what we want.
This commit essentially reverts 0494d61274, except that we now take
into account the readonly modifier to determine whether or not a
value is sent to the server, and not only the readonly attribute of
the field (which can be seen as a default). Before rev. 0494d61274,
we made a difference between write and create RPCs, for an unclear
reason. We don't do that anymore: readonly fields are never sent to
the server (same behavior as before the new views).
A problem occured with a required Many2One inside an X2Many (e.g.
order_line field in sale.order form view). If the user clicked on
'Add an item' to add a row, then typed some text in the Many2One,
then clicked on 'Create ...' to quick create a new product, and
then directly clicked on 'Add an item' to add another row (before
the name_create returned), the first row was discarded.
This was because before the name_create returns, the Many2one still
has no value, and as it is required, the row was considered invalid
and then discarded.
This rev. ensures to wait for the name_create to return before
trying to save the row and to create a new one.
Before this commit, it was not possible to reach the general settings when one
of the "default" provider was delete.
After this commit, we don't assume anymore that there are google and facebook
providers.
opw-746907
In a SO, the "Invoiced Qty" can decrease if the refund is generated from
the SO. It doesn't decrease if the refund is generated from the Invoice.
However, we don't have this mechanism in a PO since the invoice is not
generated directly from the PO. There is therefore no way to decrease
the "Billed Qty".
We authorize the "Billed Qty" to decrease in the case of PO.
Backport of c6a7e4fbb9Closes#17564
opw-747038
When an expense sheet contains several expenses with various currencies,
some issues arise:
- the currency is not specified in the form view
- the report mixes the currencies
- the total amount doesn't make any sense
Fixes#17341
opw-745714
When creating an account.payment via the form view, an onchange sets the
partner_type based on the payment_type (which has a contextual default)
and the field is view-required.
When importing however if the user does not specify a partner_type
(which they are not specifically told about) the payments will be
created with no partner_type and thus classified as "internal payments"
and will not appear in either the Sales > Payments or the Purchases >
Payments, confusing them and making them think the import has failed
despite having correctly validated and raised no errors.
Add a default_partner_type matching each action's domain (and default_payment_type) such that the imported payments are correctly classified by default.
OPW-746479
fixes#17388closes#17497
It shouldn't be possible to duplicate ir.model.fields. Add attribute
´duplicate´ which can be set to false to hide the duplication option in the
action menu.
The name of a company is uniq. The name of a company comes from a
partner and is required.
Thus duplicating a company didn't work.
With this change, if no partner is overriding the copy, the current
partner is duplicated and associated to the new duplicated company.
opw-746106
closes#17532
- Create a stockable and a service product
- In the POS, sell 1 unit of the stockable product and -1 unit of the
service product
- Validate and pay
2 pickings are created: a picking containing the stockable product which
stays in state 'Draft' and an empty picking in state 'Available'.
The problem comes from the negative quantity on a service product: we
should filter out services when checking the quantities.
opw-745712
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
backport of 74a89bcf5c
Since we handle rouding error with the last line as
the difference of total and the other (already computed),
the order of lines to process is important.
Calling 'sorted()' on the lines to process allow
to always have the same last one.
Hope this will fix the random rounding bug, and make
the multi currency test always green !
When logging timesheet, no employee is set by
default on the UI. The employee is deduced
from the user_id in the create, but we want to
see it on the list view even if it is not saved
yet.
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f
opw:746549
stock_landed_costs: on nightly, the localization installed may not have stock properties accounts defined. If it's not, we create them on the fly with a random account
sale, sale_expense: fix broken tests due to mismatch currency:
On 10.0-nightly, the currency of the company is not the same that the product.list0
that leads to assertion errors.
The karma link is an hardcoded page from odoo.com. The information might
therefore not be correct depending on the configuration of the user.
We change to redirect to the FAQ, which also contains Karma information.
opw-746383
When the field use_create_lots is set to False in a picking type, it is not possible
to create lot for a pack operation linked to this picking type.
opw:744862
Add a constrains on user_id field to avoid to recompute manually the team_id.
Eg: action_foward didn't call the onchange manually, so the saleteam not updated.
The website is not ready. It is still too young to understand what the
beautiful `_rpc` function can bring to its life. Someday it will, but
for now, it can at least rely on the `rpc.query` function or to the
'Ace' menu which now understands the beauty of `_rpc`.
---
-> Replace website `_rpc` calls with deprecated `rpc.query` as the
website is not structured enough yet to handle 'trigger_up' events.
-> As the `_rpc` calls cannot be replaced for the ace editor because it
is also used and tested in the backend, promote the 'Ace' menu (which
instantiate the ace editor) to be a `ServiceProvider` so that the
`_rpc` method works in this particular case.
If `d.message` is an empty string, `!!d.message` is false and the
crashmanager will try to display `d.error.data.message`… which does
not exist as it's a warning with an empty message not an upstream error.
That causes the crashmanager itself to crash, and even the warning
name/title to be lost.
Commits 9365482df0 and 8fc81b871d attempted to prevent the creation
of two moves with the same name during reconciliation. It works in most
cases, but it is still possible to reconcile the same statement line
with more than one line.
We add an extra check to make sure duplicate never happen.
opw-742018
This simple return allows submodules to be able to know when a dialog is shown and modify something in it.
Note from GED: I am aware that this is a IMP in a stable version, and I really don't like that... But it looks like it really helps many people, as shown by the PR, and the risk induced by this commit is definitely extremely low, so I will make an exception.
(PR: #15579)
The ModelFieldSelector keeps an internal cache for the fields_get.
This cache needs to be cleared in the tests environment because
a model with the same name may be defined several times accross the
tests modules, but they may contain different fields.
This could also be a problem with studio: when a field is created,
the ModelFieldSelector cache must be cleared as well (in addition
to the data_manager one).
We thus introduce a new 'clear_cache' event on core.bus. When
triggered, the ModelFieldSelector and the data_manager clear their
respective cache.
We use this event in the test environment to ensure that the cache
is cleared at the end of each test using a mockEnvironment. This
rev. also fixes an infinite loop in the override of destroy() in
the mockEnvironment, which occured when both session and config
were specified in the params.
When updating a carrier that is not "fixed" or "base_on_rule", this
method was creating unnecessary delivery.price.rule at each write.
This patch fixes this issue.
Closes PR #17443
Aaron Bohy