The groupby property was wrongly set in some cases: if a graph/pivot view is defined as a groupby on field F, but there is another groupby key G in the context, it will take F instead of G (at initial load).
On online quotations, a left menu is automatically generated on page
load by searching for the <h1/> and <h2/> elements in the page. This
also considered the empty ones which do not make sense and were
breaking the menu's layout. Ideally, there should not be any empty
title in the page.
opw-752764
In case a default value is set for the field `mass_mailing_name` of the
mail composer, the automatic messages sent via message_post_with_* are
considered as a mass mailing. It may also create an AccessError if the
current user is not a mass mailing user.
In the case of the "assign user" email (for auto-subscribed users), the
url wasn't shorten, which resulted in invalid links (opw-752941) (fixed
by 3228694bdd)
Previously, we had to filter the context values to exclude some
erroneous values we propagated earlier.
This commit removes the earlier propagation of wrong values (the
current record context when executing an action) and thus also
removes the filtering of those values, which was actually removing
useful values from the action context.
The bug could be seen by following these steps:
- Install crm and sale
- Go to My Pipeline
- Open an opportunity which has a customer set
- Click on "New Quotation" action button
- See that the customer is not set on the new quotation, it should
be set by the default_partner_id value in the action context
Since formatBoolean returns a jQuery object, boolean fields were
displayed as [Object object] in calendar view.
This is a fix for stable version. The real fix would be to get rid
of the jQuery object returned by formatBoolean but the change is
not trivial.
The record data given to fullCalendar to use in the renderEvent
function was not parsed like it is in basic model for example.
As a result, date(time) fields were string rather than moment
objects, which was triggering the crash that started this commit.
Execution of actions is usually done with trigger_up, which delegates
the action execution to the widget's controller.
This is troublesome for actions done on widgets that have no
controllers, like widgets in Studio for example.
The commit fixes this by adding a standalone option for AbstractFields,
if the flag is true when instantiating a widget, the action will be
called directly from within the widget object and will not be propagated
upwards.
A test to verify that this works properly has been added as well
Before this commit, the _mockNameSearch method of the mock server was
computing by hand the first element of the domain. This was adhoc and
wrong (for example, the '==' operator). Also, we actually have a method
designed to just return the records matching a given domain.
When a one2many is set through an onchange, the web client did not set
the id field properly. Because of that, it could not be displayed in a
list. This is due to the fact that the id is given in the command like this:
[1, 53, {...}]
Here, the command is 1 (update), then 53 (id), then some values, which
do not have the id. So, in this specific case, we assumed that all the
new values were in the object, even though we properly set the res_id
property.
We fix this issue at the root: in the _makeDataPoint method, we make
sure that no datapoint can be created with a res_id and without the
corresponding id key.
Note that this issue was not found in a standard installation of Odoo
(but it may be present somewhere), but in some custom code. It is rare
to actually use the id field in a view, but in this case, we had a
many2many in kanban view, and the id was used to format the url of an
image.
When an employee submits an expense, no mail is sent to the manager.
This should be the case, since it works this way on holidays.
The trick, however, is that the expense is created as submitted, but the
followers are only added afterwards. We need to make sure to add the
followers at creation.
opw-751085
Steps to reproduce:
1.Create pos order with two products.
2.One of the products, must be type="Stockable Product" and quantity=0.
3.Pay order.
4.Check order --> extra info --> picking
Bug:
picking state = Waiting Availability
In 9.0, the picking state is equal to "Done".
Fixes#18089
opw:751565
When unlinking payment terms, the ir.property records linked to
the fields "property_payment_term_id" and "property_supplier_payment_term_id"
were not deleted.
opw:749459
The accounting date is an hidden field, which is by default the invoice
date. However, a user can make it available in the interface, and modify
it.
When the accounting date is different from the invoice date, we must
make sure to make the accounting date prevail when it comes to currency
conversion. Otherwise, the account move created will use a currency
exchange rate which is not in line with its date.
opw-751848
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
The field `acquirer_reference` is not a mandatory field. If not
retrieved from the provider, it will have a NULL value in the DB, and
therefore will be `False` in Python.
The `capture` and `void` method will crash in this case, because of:
`etree.SubElement(tx, "refTransId").text = transaction_id`
opw-751231
- Set the currency precision to 0.05
- Print any QWeb report displaying amounts, e.g. the GL
The amounts are displayed with 1 digit precision instead of 2.
The formula used to compute the decimal places is actually wrong. The
correct one can be found in method `_decimal_places`. Anyway, we can use
directly the field.
opw-752283
Previously, the calendar view only shown a 1h item whatever the duration of the
maintenance, which was wrong every time the maintenance took more or less than
exactly one hour.
Adding this parameter allows showing a calendar view reflecting the real time
taken by the maintenance operation.
Closes#18072
When a user edit a record, then click on a stat button, the web client was a
little too aggressive in avoiding to reload data. It was assuming that
even if the server overrides the create method, the web client did not
need to know anything about the record before executing the action from
the stat button.
However, that assumption is incorrect: the display_name property is
needed to correctly display the breadcrumbs. For example, here is a scenario
that was not correct: open a res.partner in a form view, edit its name, then
click on one of the stat button. You will see that the breadcrumb is not
properly updated.
To fix this issue, we have to reload the record, and to properly update
the title property. In this commit, we also add a getName method in the
model.
With the new views, we introduced a system where some fields could
notify immediately the rest of the system that they have been changed.
It is really cool, it allows real time edition (with onchanges).
However, this was a little too much. In some cases (an onchange that
returns a warning), it was counterproductive. So, we decided to simply
remove the feature. This commit only make sure that it does not happen,
and we will do a deeper pass later to make sure that no useless code is
left behind.
Note that this means that we can reintroduce the functionality really
easily later, eventually protected by an attribute.
Jigar Patel