Trying to display external identifiers would make the server crash
because the method in charge of requesting the external id information
would expect an object but it was being given a string and thus not
computing the m2o_value for the record.
This commit fixes this by changing FieldMany2One objects' m2o_value
instatiation to use its _formatValue method to compute it, _formatValue
is then overridden in FieldReference so that it properly handles both
strings and objects to calculate its m2o_value and relation.
Before this commit, the makeDefaultRecord could return a rejected
deferred if the onchange returned a warning. This was useful in this
usecase: the user is in a form view with a one2many (for example, an
invoice with no customer set), then click on 'Add a line' (the invoice
line). In that case, the onchange returns a warning, and we do not want
to add the line at all, so the makeDefaultRecord is rejected.
This works fine, but we then have another problem: when we create a new
record from scratch, it may happen that a warning is returned (for
example, if a vendor has its 'warning on invoice' flag set, then a
purchase order is done with this vendor, then confirmed, then the stat
button for 'vendor bills' is clicked, which opens a list view with the
vendor in the context. Clicking on 'create' will return a warning,
which is what we want). In that case, the record still needs to be
created.
To solve this issue, we simply add an option to the makeDefaultRecord
function to prevent rejecting the deferred.
Create a company, try to install a coa without specify an Interbank Transfer Account (required field):
The COA can't be installed due to the missing Interbank Transfer Account that will be created by the COA... that leads to a "deadlock".
-opw: 752928
This fix previous commit a29f7f671b.
(1) Some objects have no color field.
(2) There was an issue when two many2many tags were instantiated:
If the first one had the 'color_field' attribute the second one
had it too even if this attribute weren't specified.
Now, it's fixed in data_manager
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
The state of the search bar (expanded or not) is supposed to be saved
into a local storage variable which is retrieved whenever loading a view
that has the search bar in it and it is expanded automatically if it was
done previously in any other view, this didn't happen previous to this
commit because the variable wasn't being set properly (missing key).
Before this revision, multiline links in form views had a different
colour depending on whether we were editing a record, or merely
viewing it.
As an example, the 'customer' field (containing both the name and the
address) in the form view of 'invoice' is affected. When editing the
invoice, all lines have @link-color as colour. However, when viewing it,
only the first line does, while the address is in @odoo-main-text-color.
This commit aims to replicate saas-15 behaviour when adding columns in
a Kanban view by not folding the column quick create widget when
creating a new column, thereby allowing users to add multiple columns in
one go.
For uploaded modules (e.g. saas), uploaded assets are stored in
attachments.
When the asset content is retrieved, static "filesystem" files are
assumed to be UTF8 and properly decoded, but attachment data is not
and is thus interpreted as ASCII further down the line, leading to a
UnicodeDecodeError (and a broken page/template/...) if the asset data
is not actually ASCII (e.g. if it's UTF-8).
Fix by treating attachment assets as UTF8 encoded, same as filesystem
assets.
OPW-752858
It was possible to set a payable account for an expense.
So it raised a UserError when reconciling the lines in
function expense_post_payment because two different accounts
were used as payable account.
A expense account is expected as account for an expense.
opw:752695
In an editable list view, the translation icon would display incorrectly
(out of place) for translatable char fields. This can be traced back to
two reasons, compared to saas-15:
- We now use tables instead of divs for list views
- The translate icon would have inline css that would override its
positioning with top and left attributes
This is fixed by adding top and left attributes to translate buttons
inside a field inside a table cell using CSS classes
When trying to close a POS session (which confirms the bank statements
which reconciles the statement lines) if one of the statement lines
has an amount of 0 no payment object is
created (addons/account/models/account_bank_statement.py:905) and thus
``payment`` remains set to ``False``. In the past this was not an
issue but since b17e4a0f6b at the end of
the method (line addons/account/models/account_bank_statement.py:1003)
we unconditionally write to ``payment`` which blows up when it's
``False`` rather than a recordset.
This can happen if e.g. a POS order is composed only of free
products (don't ask...)
Fix by using an empty recordset instead of a boolean for a
non-payment, making payment.write a no-op.
OPW-752922
Before this revision, double-clicking links in a modal triggered a
traceback. This is because the second click attempts to change the
active view while it is still being changed by the first click (more
precisely, the controller of the active view is undefined on the second
click).
This commit ensures that on_attach_callback is called only if the
controller is defined.
Steps to reproduce the issue fixed by this commit:
1. Open a sales order;
2. Click on a product line;
3. Double-click on the product.
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
Elkasitu